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Preface 



This volume contains the refereed proceedings of the first edition of three work- 
shops colocated with the International Conference on Formal Techniques for 
Networked and Distributed Systems (FORTE). The workshops took place in 
Toledo (Spain) on the 1st and 2nd of October of 2004, and they dealt with dif- 
ferent topics related to the application of formal methods. The names of the 
workshops were the following: 

— TlreFormEMC: 1st International Workshop on Theory Building and Formal 
Methods in Electronic/Mobile Commerce 

— EPEW: 1st European Performance Engineering Workshop 

— ITM: 1st International Workshop on Integration of Testing Methodologies 

In total, the calls for papers of the workshops attracted 62 high-quality sub- 
missions. The program committees of the workshops selected 27 papers after a 
rigorous review process in which every paper was reviewed by at least three re- 
viewers. In these proceedings, the papers are grouped according to the workshop 
they belong to. In addition to the selected papers, there was a keynote speech 
by Prof. Rob Pooley, from the Heriot-Watt University, UK. 

We want to express our gratitude for their financial support both to the Uni- 
versidad de Castilla-La Mancha and to the Junta de Comunidades de Castilla-La 
Mancha. Besides, we are in debt to all the authors who submitted high-quality 
papers to the workshops: Without their effort and interest, it would have been 
impossible to organize the workshops. We would also like to thank the program 
committee members of the three workshops for their collaboration during the 
reviewing process. Last, but not least, we would like to thank the organizers of 
each of the workshops for their hire work. 

In the next pages of this preface, the main characteristics of each of the 
workshops are described. We hope that these proceedings will be interesting not 
only for the workshop attendants, but also for a wider community of researchers 
working on the application of formal methods. 

October 2004 Manuel Nunez 

Zakaria Maamar 
Fernando L. Pelayo 
Key Pousttchi 
Fernando Rubio 
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Electronic commerce (e-commerce) places new demands not only on support and 
delivery information technology, but also on the way business processes have to 
be designed, implemented, monitored, and maintained. Reliability, efficiency, 
scalability, and fault-tolerance are among the features that have to be embedded 
into e-commerce processes. Initially, research focused on how to deal with the 
technical issues. However, the increasing challenges of deploying reliable, effi- 
cient, secure, and fault-tolerant applications have highlighted the added value of 
having theoretical foundations and rigorous formal methods for specifying and 
validating the design of such applications. In addition, new possibilities extend 
static systems with mobility capabilities. In this sense, the TheFormEMC work- 
shop tried to get together researchers working on theoretical aspects that can 
be applied to e-commerce and m-commerce systems. 

The TheFormEMC workshop attracted 16 high-quality submissions from 9 
different countries. The multidisciplinary nature of e-commerce and m-commerce 
technologies presents challenges for evaluating technical papers. The program 
committee comprised of experts from several disciplines selected 8 papers after 
a rigorous double-blind review process in which every paper was reviewed by at 
least three reviewers. 
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EPEW is a new European forum for the presentation of all aspects of per- 
formance modelling and analysis of computer and telecommunication systems. 
The EPEW workshop attracted 36 high-quality submissions from 15 different 
countries. The program committee comprised of experts from several disciplines 
selected 14 papers after a rigorous review process in which every paper was re- 
viewed by at least three reviewers. The 14 accepted papers cover a broad range 
of topics including performance modelling and analysis of computer systems 
and networks, performance engineering tools, formal modelling paradigms and 
methods for performance prediction. 
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ITM 

Even though testing activities are considered to be rather important, we have to 
overcome the problem that different testing communities use different methods. 
We may roughly identify two testing communities: testing of software, and test- 
ing of communicating systems. Until very recently, research had been carried 
out with almost no interactions between these two communities, even though 
they have complementary know-how. The ITM workshop has born to help find 
a synthesis between the different techniques developed by each community. 

The ITM workshop attracted 10 high-quality submissions from 7 different 
countries. The program committee selected 5 papers after a rigorous review 
process in which every paper was reviewed by at least three reviewers. The papers 
present a well-balanced view of testing technologies, combining both theoretical 
and practical issues. 
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of the Internet Open Trading Protocol 



Chun Ouyang and Jonathan Billington 

Computer Systems Engineering Centre 
School of Electrical and Information Engineering 
University of South Australia, SA 5095, AUSTRALIA 
{Chun . Ouyang , Jonathan . BillingtonjSunisa . edu . au 



Abstract. The Internet Open Trading Protocol (IOTP) is an electronic 
commerce (e-commerce) protocol developed by the Internet Engineering 
Task Force (IETF) to support online trading activities. The core of IOTP 
is a set of financial transactions and therefore it is vitally important that 
the protocol operates correctly. An informal specification of IOTP is pub- 
lished as Request For Comments (RFC) 2801. We have applied the formal 
method of Coloured Petri Nets (CPNs) to obtain a formal specification 
of IOTP. Based on the IOTP CPN specification, this paper presents 
a detailed investigation of a set of behavioural properties of IOTP using 
state space techniques. The analysis reveals deficiencies in the termina- 
tion of IOTP transactions, demonstrating the benefit of applying formal 
methods to the specification and verification of e-commerce protocols. 



1 Introduction 

Electronic commerce (e-commerce) applications are susceptible to failures if the 
underlying protocols are not properly designed and analysed. These failures could 
result in financial loss to any participant, e.g., commercial traders, financial insti- 
tutions or consumers. However, ensuring the correctness of complex e-commerce 
protocols is a difficult task and informal methods are inadequate. Formal meth- 
ods [6] are necessary for the construction of unambiguous and precise models 
that can be analysed to identify errors and verify correctness before implemen- 
tation. Application of formal methods will lead to more reliable and trustworthy 
e-commerce protocols [16]. 

An important example of an e-commerce protocol is the Internet Open 
Trading Protocol (IOTP) [5] developed by the Internet Engineering Task Force 
(IETF) to support trading activities over the Internet. It is also referred to as a 
shopping protocol [3, 10] which encapsulates different payment systems such as 
Secure Electronic Transaction (SET) [18] and Mondex [11]. The specification of 
IOTP, Request For Comments (RFC) 2801 [4], is the largest RFC developed by 
IETF spanning 290 pages. The RFC contains an informal narrative description 
of IOTP, and so far no complete implementation of IOTP exists [17, 7]. The 
development of IOTP is still in an early stage and can therefore benefit from the 
use of formal methods to verify its functional correctness. 



M. Nunez et al. (Eds.): FORTE 2004 Workshops, LNCS 3236, pp. 1—15, 2004. 
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We apply Coloured Petri Nets (CPNs) [8] to model and analyse IOTP. CPNs 
are a formal modelling technique that combines the graphical notation of Petri 
nets with the power of abstract data types allowing data and control flow to be 
visualised. CPNs have been used successfully for protocol modelling and analysis 
for 2 decades [2]. Babich and Deotto [1] provide a recent survey comparing this 
approach with the other main approaches. CPN models are executable and can 
be analysed using state spaces to detect errors such as deadlocks. We use a tool 
called Design/CPN [12] for constructing and analysing our CPN models. 

In previous work [14], we developed a hierarchical formal specification of 
IOTP and briefly mentioned some initial analysis results. In contrast, this pa- 
per describes our analysis approach in detail. With the state space generated 
from the CPN model, we investigate and formally reason about a set of desired 
properties of IOTP (e.g., correct termination). The analysis reveals errors in the 
current design. 

The paper is organised as follows. Section 2 gives an introduction to IOTP’s 
basic concepts and procedures. Section 3 describes the IOTP CPN specification, 
with focus on its hierarchical structure. Section 4 presents a detailed investigation 
of several desired properties of IOTP. Finally, we conclude this paper and discuss 
future work in Sect. 5. 

2 The Internet Open Trading Protocol 

IOTP [4] focuses on consumer-to-business e-commerce applications. It defines 
five trading roles to identify the different roles that organisations can assume 
while trading. These are Consumer, Merchant, Payment Handler (a bank), De- 
livery Handler (a courier firm) and Merchant Customer Care Provider. The 
core of IOTP is an Authentication transaction and five payment-related transac- 
tions named Purchase, Deposit, Withdrawal, Refund and Value Exchange. Each 
transaction comprises a sequence of message exchanges between trading roles. 

Document Exchanges and Transactions. IOTP defines a set of document 
exchanges as building blocks for implementation of transactions. These are: Au- 
thentication, Brand Dependent Offer, Brand Independent Offer, Payment , Deliv- 
ery, and Payment-and-Delivery . An Authentication transaction consists of just 
an Authentication (document) exchange. A Purchase transaction comprises an 
optional Authentication, an Offer (either a Brand Dependent Offer or a Brand 
Independent Offer), and then, a Payment exchange, a Payment followed by a De- 
livery exchange, or a Payment-and-Delivery exchange. A Deposit, Withdrawal, or 
Refund transaction starts with an optional Authentication, an Offer, and a Pay- 
ment exchange. Finally, a Value Exchange transaction begins with an optional 
Authentication followed by an Offer and two Payment exchanges in sequence. 

Below, we consider an example of a Purchase transaction which comprises an 
Authentication, a Brand Dependent Offer, and a Payment followed by a Delivery 
exchange. Figure 1 shows a possible sequence of messages exchanged between 
the four trading roles involved in the transaction. 
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Phase Event Consumer 
No. 

1 
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Payment Response 



Payment Handler 
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Delivery Request 



Delivery Response 



=► IOTP message exchanges 



Outside the scope of Baseline IOTP 



Fig. 1 . A possible sequence of message exchanges in a Purchase transaction 



In the beginning, the Consumer decides to buy goods, and sends a Purchase 
Request (event 1) to the Merchant. This event initiates a Purchase transaction, 
however it is not part of Baseline IOTP. 

Upon receiving the Purchase Request, the Merchant starts an Authentication 
document exchange (events 2-4) to verify the bona fides of the Consumer. In 
IOTP’s terminology, the Merchant acts as the Authenticator and the Consumer 
the Authenticatee. At first, an Authentication Request is issued by the Merchant 
(event 2), specifying the authentication algorithm to be used. As a result, the 
Consumer replies with an Authentication Response containing the authentication 
data obtained using the above algorithm (event 3). After verifying the Con- 
sumer’s response, the Merchant generates an Authentication Status indicating 
that the authentication is successful (see event 4). 

Once the authentication completes, the Merchant continues to a Brand De- 
pendent Offer document exchange (events 4-6) by providing the Consumer a list 
of Trading Protocol Options (TPO). This includes the available payment meth- 
ods and associated payment protocols. The message combining the TPO and 
the above Authentication Status is then sent to the Consumer (event 4). The 
Consumer chooses one of the options, and sends it back as a TPO Selection 
(event 5). The Merchant uses the selection to create and send back an Offer 
Response (event 6), which contains details of the goods to be purchased together 
with payment and delivery instructions. 

Next, a Payment document exchange starts between the Consumer and the 
Payment Handler (events 7-9). After checking the Offer Response for purchase 
details, the Consumer sends the Payment Handler a Payment Request (event 7). 
The Payment Handler checks the Payment Request, and if valid, the payment is 
conducted using Payment Protocol Data exchanges (events 8) as determined by 
the encapsulated payment protocol (e.g., SET). After the payment protocol data 
exchange has finished, the Payment Handler sends a Payment Response (event 9) 
containing the payment result (e.g., receipt). 
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Finally, a Delivery document exchange is carried out between the Consumer 
and the Delivery Handler (events 10-11). After checking the Payment Response, 
the Consumer sends the Delivery Handler a Delivery Request (event 10). The De- 
livery Handler schedules the delivery and sends the Consumer a Delivery Response 
(event 11) containing details of the delivery, and possibly the actual delivery if 
the goods are electronic (e.g., an e-journal). 

Also, it should be mentioned that event 5 in the above scenario may or may 
not take place in an Offer exchange, which results in the distinction between 
a Brand Dependent Offer and a Brand Independent Offer. The Brand Depen- 
dent Offer occurs when the Merchant offers some additional benefit (e.g., price 
discount) in the Offer Response depending on the specific payment brand (e.g., 
VISA or MasterCard) chosen in the Consumer’s TPO Selection. In the Brand In- 
dependent Offer, the Offer Response is independent of the payment brand selected 
by the Consumer. In this case, the Merchant does not require the Consumer’s 
TPO Selection before the Offer Response can be generated. IOTP defines a com- 
bined TPO and Offer Response message to be used in the Brand Independent 
Offer. 

Transaction Cancellation and Error Handling. These are two important 
procedures related to IOTP transactions. A transaction may be cancelled by any 
trading role engaged in that transaction. For example, in the Purchase trans- 
action shown in Fig. 1, the Merchant would cancel the transaction if the Con- 
sumer’s Authentication Response has failed. Error handling is concerned with how 
trading roles handle technical errors and exceptions that occur during a transac- 
tion. For example, in Fig. 1, the Merchant may re-send the TPO upon a time-out 
when expecting the Consumer’s TPO Selection. A Cancel message is used for 
transaction cancellation and an Error message for reporting errors. 

3 A Formal Specification of IOTP 

RFC 2801 [4] contains an informal narrative description of IOTP and suffers 
from ambiguities and incompleteness. We have created a CPN model of IOTP 
to obtain a formal specification of IOTP that truly reflects the intent of its RFC 
specification. When ambiguities and gaps are detected, assumptions are made to 
clarify the ambiguities and fill in the gaps. A detailed description of this formal 
specification of IOTP is presented in [14]. Figure 2 shows the hierarchy page for 
the IOTP CPN model. It provides an overview of the pages (modules) constitut- 
ing the model. There are 31 pages organised into four hierarchical levels. An arc 
between two pages indicates that the destination page is a subpage (submodule) 
of the source page. The four-level hierarchy of the IOTP CPN model provides 
a logical structure that can be validated against RFC 2801. 

The first (top) level presents an abstract view of IOTP on one page, namely 
IOTP_TopLevel. It has four subpages: Consumer, Merchant, PHandler and DHan- 



Formal Analysis of the Internet Open Trading Protocol 



5 



■{ Purchase_C#8 ) 



Deposit_C/ 

WithdrawaLC/ 

Refund_C#9 



( ValExTr_C#10 



Auth 


^ Auth 


^ Auth 


V Auth 


^ Cancel 


v BDOfr 


„ BDOfr 


^ BDOfr 


v BlOfr 


„ BlOfr 


S BlOfr 


v Pay 


^ Pay 


J>ay1 2 


^PayDIv 






^Deliv 






^Cancel 


^ Cancel 


^Cancel 


^ErrHdl 


^ErrHdl 


v ErrHdl 


^ ErrHdl 



{ Cancellation_C#29 



( IOTP_TopLevel#1 ]_ 
Merchant 
[ Merchant#4 




AuthTr_M#11 



Purchase_M/ 

Deposit_M/ 

WithdrawaLM/ 

Refund_M/ 

ValExTr_M#12 



Authenticatee#17 ) ( Authenticatorffi 8 1 

>Offer_C#19~) (BrdDepOffer_M#2Q ] 



BrdlndOffer_C#21 ~*) ( BrdlndOffer_M#22 



— » ( PayDelivery_C#25 ) 
— »{ Delivery_C#27 ) 



) G 



Cancellation_NC#30 >< 



V^ErrHdl ^ ErrHandling_C#31~~] ( ErrHandling_NC#32 ^ ErrHd l/ 



>(Purchase_P#13 ) 



Deposit 
Withdrawal _ 
Refund 



Deposit_P/ 

WithdrawaLP/ 

Refund_P#14 



[ ValExTr_P#15 ) 



( Payment_P#24 ] 
(PayDelivery_P#26 ] 



Pay1_2y Pay j Pi 



PHandler#6 ) 



( Purchase_P#1 6~~) 



( Pelivery_P#28 

Cancel 



Fig. 2. The hierarchy page of the IOTP CPN model 



dler, corresponding to four trading roles 1 . We refer to these pages as trading role 
pages, which comprise the second level of the IOTP CPN model. 

Each trading role page has a set of subpages specifying the possible Au- 
thentication and Payment-related transactions for that trading role. All these 
subpages, which we call transaction pages , constitute the third level of the model. 
For example, the page Consumer has four subpages modelling six transactions 
for the Consumer. The three transactions Deposit, Withdrawal and Refund 
use the same procedure and therefore are modelled on one page named De- 
posit_C/Withdrawal_C/Refund_C. The initial letter of each trading role name is 
used as a suffix of the name of transaction pages modelled for that trading role. 
For example, the subpages AuthTr_C and AuthTr_M represent an Authentication 
transaction between the Consumer and Merchant. It can be seen that both the 
Consumer and the Merchant are involved in all six transactions, the Payment 
Handler is engaged in all transactions except Authentication and the Delivery 
Handler is only involved in Purchase transactions. 

Each transaction page is further decomposed into a set of subpages modelling 
the document exchanges that are used to construct that transaction as well as 
the error handling and cancellation procedures. All these subpages, which we 
call exchange level pages, constitute the fourth level of the model. For example, 
the page Purchase_C has six subpages modelling the six document exchanges 
used to implement a Purchase transaction for the Consumer and two others 
modelling how the Consumer handles technical errors and cancels an ongoing 
transaction. Since a document exchange always involves two trading roles, we 
have modelled each exchange as a pair of pages - one for each trading role. For 
example, the pages Authenticates and Authenticator represent an Authentication 

1 The Merchant Customer Care Provider, currently not used in any transactions, is 
not modelled. 
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document exchange where the Consumer is authenticated by the Merchant. In 
a similar way to the transaction pages, most of the exchange level pages have 
a name which is suffixed by the initial letter of the corresponding trading role. 
For example, the pages Delivery_C and Delivery_D represent a Delivery document 
exchange between the Consumer and the Delivery Handler. In addition, the 
procedures of error handling and transaction cancellation are different between 
Consumer and non-Consumer entities. We have also modelled each of these two 
procedures using only a pair of pages - one (whose name ends with the letter C) 
for the Consumer, the other (whose name ends with the two letters NC) for any 
non-Consumer entity (Merchant, Payment Handler or Delivery Handler). Each 
pair of ErrHandling or Cancellation pages are used by all transaction pages. 

4 Formal Analysis of IOTP Properties 

We use state space analysis to investigate the functional behaviour of IOTP. In 
state space analysis we generate all system execution paths and store them as 
a directed graph (called a state space). Nodes in the state space represent states, 
and arcs represent state changes. The state of a CPN is called a marking, and the 
state changes are represented by occurrences of transitions where a transition 
in CPNs represents an event. The state space of the IOTP CPN model can be 
generated, allowing several properties of IOTP to be verified. 

4.1 Analysis Approach 

Our analysis of IOTP focuses on the six Authentication and Payment-related 
transactions. The IOTP CPN model specifies these six transactions in a modu- 
lar fashion. All six transactions are independent of each other and it is therefore 
valid to analyse one transaction at a time. For the analysis of a particular trans- 
action, the IOTP CPN model needs to be initialized for the execution of that 
transaction only. This is given by the Transaction parameter used in the model. 
For example, if Transaction has a value Purchase, the IOTP CPN model can 
be executed to capture all possible executions of a Purchase transaction and 
to generate the state space for the transaction. For each transaction, there are 
also different cases we can analyse by changing the maximum value of the mes- 
sage retransmission counters (denoted by RCmax) for each of the four trading 
roles. Once the number of retransmissions reaches RCmax, the transaction will 
be cancelled. Accordingly, the analysis of transactions involves selecting appro- 
priate values for both the Transaction and RCmax parameters, and thereby 
defining the configurations of IOTP. 

IOTP is designed to be payment system-independent. A Payment document 
exchange may involve payment data exchanges that can occur any finite num- 
ber of times (see event 8 in Fig. 1), catering for various payment systems to be 
encapsulated by IOTP. In the IOTP CPN model, the message identifier is used 
for checking duplicates, and is incremented with each payment data exchange. 
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As a result, we obtain infinite state space if the number of payment data ex- 
changes is unbounded. However, in the current design of IOTP [4], a payment 
data exchange is only used to encapsulate payment system-specific messages 
(e.g., a SET message) and its occurrence in a (Payment-related) transaction is 
optional. This allows us to hide any payment data exchange from the analysis 
of the core behaviour of each Payment-related transaction. 

4.2 Desired Properties of IOTP Transactions 

We define three properties that IOTP transactions should satisfy: proper ter- 
mination in terms of absence of undesired terminal states; absence of undesired 
cycles; and absence of procedures that are specified but never executed. 

Property 1 (Valid Transaction Termination) . The dead markings in each trans- 
action state space represent all valid terminal states of that transaction. 

A dead marking of a CPN model is a marking in which no transitions can 
occur. The set of dead markings in the state space of a transaction therefore de- 
fines the terminal states of the transaction. If a transaction terminates properly, 
each of the trading roles that have started the transaction must enter a valid 
terminal state. In the IOTP CPN model, there are two valid terminal states for 
a trading role: COMPLETED indicating that a transaction terminates successfully, 
and CANCELLED indicating the transaction is cancelled. It follows from Property 1 
that any dead marking that does not represent the valid transaction termination 
is undesirable, i.e. , a deadlock. So, if Property 1 is true, we can prove that the 
transaction is deadlock free. 

Property 2 (Absence of Livelocks). There must be no livelocks in each transac- 
tion state space. 

If a state space contains a cycle that leads to no markings outside the cycle, 
then once the cycle is entered it will repeat for ever. This is called a livelock. 
A transaction, which provides meaningful operations and terminates properly, 
should be free from livelocks. A strongly connected component (SCC) of the 
state space is a maximal sub-graph whose nodes are mutually reachable from 
each other [9]. If the state space is isomorphic to the SCC graph, and contains 
no self-loops, then the state space has no livelocks. If Property 2 is true, we 
can prove that it is always possible for a transaction to terminate in one of the 
terminal states represented by dead markings. 

Property 3 (Absence of Unexpected Dead Transitions) . There must be no unex- 
pected dead transitions in each transaction state space, unless those transitions 
model events that are not activated under certain configurations of IOTP. 

If a transition is not able to occur in any reachable marking then this transi- 
tion is a dead transition. A dead transition in a transaction state space of IOTP 
indicates the protocol operation modelled by that transition never occurs. We 
expect transitions which model protocol operations that are not activated under 
certain configurations of IOTP to be dead. An unexpected dead transition means 
a protocol operation is redundant or that unexpected behaviour has occurred, 
resulting in that operation not being utilized. 
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Table 1. State space size and number of dead markings for Configuration Set 1 



Configuration 


Nodes 


Arcs 


Dead markings 


Time(sec) 


(Authentication, 1) 


276 


759 


4 


1 


(Purchase, 1) 


3695 


10021 


37 


28 


(Deposit, 1)/ 
(Withdrawal, 1)/ 
(Refund, 1) 


2465 


7021 


19 


16 


(ValueExchange, 1) 


2919 


8148 


25 


20 



4.3 State Spaces for Selected Configurations of IOTP 

Six configurations of IOTP are used for our analysis. They represent each of 
the six Authentication and Payment-related transactions and have the RCmax 
parameter set to 1, allowing a single retransmission of an IOTP message at each 
trading role. A configuration is denoted by a pair of values - one assigned to 
the Transaction parameter, the other to RCmax. For example, (Purchase, 1) 
denotes the configuration of a Purchase transaction in which all the trading 
roles cannot re-send a message more than once. Also, we refer to the set of 
configurations with RCmax = 1 as Configuration Set 1. 

The state spaces are generated for the IOTP CPN model with configurations 
in Configuration Set 1, using Design/CPN. Table 1 summarises the statistics of 
the state space size, the number of dead markings and the generation time (on 
a 700MHz Intel Pentium computer with 512MB RAM), for each configuration. 



4.4 Analysis of Transaction Termination Property 

By examining the dead markings in the state space of a transaction, we can 
determine whether the transaction terminates properly. Below, we illustrate our 
approach to the inspection of all terminal states of an IOTP transaction, using 
Purchase as a representative example. The Purchase transaction involves four 
trading roles and six document exchanges, and is thus the most complicated 
among all IOTP transactions. 

Table 2 lists 37 dead markings in the state space of the transaction with 
configuration (Purchase, 1). The corresponding states of each trading role are: 
CMP for COMPLETED and CNL for CANCELLED. The subscript of a state specifies the 
document exchange in question, i.e. , Auth for Authentication, BDOfr for Brand 
Dependent Offer and BlOfr for Brand Independent Offer, Pay for Payment and 
PayDIv for Payment-and-Delivery. The subscript NoExch is used when it is not 
clear which document exchange to start. A trading role without the above in- 
formation (represented by is not involved, or has not yet started, in the 
transaction. We divide the above dead markings into seven groups with their 
group numbers given in the first column of Table 2. In the following, the trans- 
action with configuration (Purchase, 1) is referred to as transaction (Purchase, 1 ), 
and marking n is written as M n . 
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Table 2. Dead markings of the transaction with configuration (Purchase, 1) 



Group 


Dead 


Trading role state 


No. 


markings 


Consumer 


Merchant 


PHandler 


DHandler 


1 


1145, 555 


CMPpay 


CMPBDOfr, BlOfr 


CMPpay 


- 




2144 , 1423 


CMPpgyDIv 


CMP B DOfr, BlOfr 


CMPpayDIv 


- 




2376, 1655 


CMPoeliv 


CMP B DOfr, BlOfr 


CMPpay 


CMPoeliv 


2 


36, 47, 42 


CNLMoExch 


CNLAuth, BDOfr, BlOfr 


- 


- 




65 


CNLAuth 


CNLAuth 


- 


- 




80 


CNLBDOfr 


CNLBDOfr 


- 


- 




152 


CNLsiOfr 


CNLeiofr 


- 


- 




472, 453 


CNLAuth 


CNLBDOfr, BlOfr 


- 


- 


3 


1626, 954 


CNLpay 


CNL B DOfr, BlOfr 


CMPpay 


- 


4 


929, 393 


CNLpay 


CMPBDOfr, BlOfr 


CNL|\JoExch 


- 




1156, 566 


CNLpayDIv 


CMPBDOfr, BlOfr 


CNL|\JoExch 


- 




1142, 552 


CNLpay 


CMP B DOfr, BlOfr 


CNLpay 


- 




1638, 966 


CNLpayDIv 


CMPBDOfr, BlOfr 


CNLpayDIv 


- 


5 


2121, 1400 


CNLD e |i v 


CMP B DOfr, BlOfr 


CMPpay 


CNL|\| 0 Exch 




2374, 1653 


CNLoeliv 


CMPBDOfr, BlOfr 


CMPpay 


CNLoeliv 


6 


47, 619 


CNL|\|oExch, Auth 


CMPsiOfr 


- 


- 




382 


CNLBDOfr 


CMP B DOfr 


- 


- 


7 


1378, 748 


CNLpay 


CMPBDOfr, BlOfr 


CMPpay 


- 




2146, 1425 


CNLpayDIv 


CMP B DOfr, BlOfr 


CMPpayDIv 


- 




2608, 1916 


CNLoeliv 


CMPBDOfr, BlOfr 


CMPpay 


CMPoeliv 



Successful Transaction Termination. The dead markings in Group 1 repre- 
sent all successful terminations of a Purchase transaction. The transaction may 
be completed with 1) the Payment exchange in M1145 or M555; 2) the Payment- 
and-Delivery exchange in M2144 or -M1423; or 3) the Delivery exchange in M2376 
or Mi 6 55. Figure 3 shows a path leading to M2376 in the state space of transac- 
tion (Purchase, 1). A node represents a marking, e.g., the node number 2376 (on 
bottom right of Fig. 3) represents An arc represents a transition occur- 

rence, and the dashed box attached to the arc lists the occurring transition. For 
example, the arc number 1 leading from node 1 to node 2 (written as 1 : 1 — ^2 in 
the dashed box) represents the occurrence of transition initiateTr_M on page Mer- 
chant (written as Merchant'lnitiateTr_M in the dashed box), upon which the state 
of the transaction changes from M\ to M2. The sequence of transition occur- 
rences defined by the path shown in Fig. 3, captures the Purchase transaction 
scenario shown in Fig. 1. For example, the sequence of transition occurrences 
represented by the arc list (3,8,18) in Fig. 3 corresponds to event 2 in Fig. 1. 

Cancelled Transaction between Consumer and Merchant. The dead 
markings in Group 2 represent the transaction being cancelled between the Con- 
sumer and Merchant, after the Merchant has initiated an Authentication or Of- 
fer exchange but before the Consumer starts a Payment exchange. In M36, M47 
and M42, the transaction is cancelled before the Consumer initiates an Au- 
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Fig. 3. A path leading to M2376 in the state space of transaction (Purchase, 1) and 
capturing the Purchase transaction scenario shown in Fig. 1 



thentication or Offer exchange at the beginning of the transaction. In M 65, the 
transaction is cancelled during an Authentication exchange. In Mgg and -M152, 
the transaction is cancelled during an Offer exchange. In IW472 and M453, the 
transaction is cancelled within an Authentication exchange at the Consumer, 
while it is cancelled within an Offer exchange at the Merchant. These two mark- 
ings are expected because of combining the Authentication Status with the first 
message in the Offer exchange. Figure 4 shows a path leading to M472 in the 
state space of transaction (Purchase, 1) (Fig. 4 (a)) and the transaction scenario 
captured by the corresponding sequence of transition occurrences (Fig. 4 (b)). In 
this scenario, the Consumer cancels the transaction (Cancellation_C’SndCnl, M196 
to M313 in Fig. 4 (a)) before receiving the Authentication Status & TPO message 
from the Merchant, and is therefore still in the Authentication exchange when 
the transaction is cancelled. Also, the Consumer discards any message received 
after the transaction has been cancelled (ErrHandling_C’Discard, M464 to M472 in 
Fig. 4 (a)), e.g., the Authentication Status & TPO message in the above scenario. 

The dead markings in Group 3 represent the transaction being cancelled be- 
tween the Consumer and Merchant, after the Payment exchange has completed 
but before the Delivery exchange starts. As defined in IOTP, the Consumer gen- 
erates and sends a Cancel message to the Merchant but not the Payment Handler. 
As a result, the Merchant enters the CANCELLED state and the Payment Han- 
dler remains in COMPLETED. Since the Merchant is aware of the cancellation, the 
Consumer would be able to receive a refund by initiating a Refund transaction. 

Merchant not Informed of Transaction Cancellation between Other 
Trading Roles. The dead markings in Groups 4 and 5 represent the transaction 
being cancelled between the Consumer and the Payment Handler or Delivery 
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Consumer 



Merchant 



Authentication 

Request 



Authentication 

Response 



CNL Auth 

Discard 



Cancel 



Authentication 
Status & TPO 



CNL BDOfr 



(a) (b) 

Fig. 4. Inspection of M 472 in the state space of transaction (Purchase, 1): (a) a path 
leading to M 472 in the state space and (b) the corresponding transaction scenario 



Handler. According to IOTP, the Merchant is not informed of such transaction 
cancellation and therefore remains in the COMPLETED state when the transaction 
is cancelled. Closer inspection reveals deficiencies related to the corresponding 
transaction terminations. 

In Group 4, the Merchant may have received the goods from the manufacturer 
but unexpectedly the Consumer does not purchase the goods. Since the Merchant 
is not aware of the transaction cancellation between the Consumer and Payment 
Handler, the Merchant still expects the purchase to proceed. This may result in 
an inventory problem , i.e, goods building up in the Merchant’s warehouse. 

In Group 5, neither the Merchant nor the Payment Handler is notified of the 
cancellation between the Consumer and Delivery Handler. In this case, the Con- 
sumer will not receive the goods that was paid for, the Merchant will expect the 
goods to be delivered, and the Payment Handler will believe that the payment 
is completed. This situation may be recovered by the Consumer invoking a Re- 
fund transaction where evidence of the payment (e.g., the payment receipt) is 
provided to the Merchant. However, the Merchant will need to check (somehow) 
that the goods were not delivered to that Consumer. If the Consumer does not 
request a refund, then the inventory problem remains. 

Transaction Cancelled at Consumer but Completed at Other Trading 
Roles. The dead markings in Groups 6 and 7 represent a Purchase transaction 
being cancelled at the Consumer side only. 

In Group 6, the cancelled transaction involves just two trading roles, the 
Consumer and the Merchant. This does no harm to the Consumer since no 
payment has yet been made, but it may still result in the inventory problem. 

In Group 7, the transaction is cancelled after the Payment Handler has com- 
pleted the Payment exchange, and the cancellation is evident at the Consumer 
only. Since all the other trading roles involved in the transaction believe that 
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Consumer 



Merchant 



TPO & Offer Response 



CMP BIOfr 



Payment 

Handler 



Payment Request 




CNL p a y 

Discard 



Cancel 




CMP p ay 
Discard 



1 ^ Payment Response 



(a) 



(b) 



Fig. 5. Inspection of M748 in the state space of transaction (Purchase, 1): (a) a path 
leading to M748 in the state space and (b) the corresponding transaction scenario 



the transaction has successfully terminated, it may result in a non-refundable 
payment problem , i.e. , the Consumer not being able to obtain a refund. For 
example, Fig. 5 shows a path leading to M748 in the state space of transac- 
tion (Purchase, 1) (Fig. 5 (a)) and the transaction scenario captured by the 
corresponding sequence of transition occurrences (Fig. 5 (b)). In this scenario, 
the Consumer cancels the transaction (Cancellation_C’SndCnl, M258 to in 

Fig. 5 (a)) before receiving the Payment Response. However, the Payment Han- 
dler has already sent the Payment Response and entered the COMPLETED state 
(Payment.P’SndCnl, M 38 g to M 550 in Fig. 5 (a)) and therefore discards the 
Cancel message from the Consumer (ErrHandling_NC'Discard_P, M550 to M742 
in Fig. 5 (a)). The Merchant is not notified of the cancellation and therefore 
remains in COMPLETED. 

From the above, the dead markings in Groups 4 to 7 represent undesired 
terminations of a Purchase transaction, where an inventory problem may occur 
at the Merchant (Groups 4 to 6) or a non-refundable payment problem may 
occur to the Consumer (Group 7). 

Analysis of the transaction termination properties of other transactions (in 
Configuration Set 1) is performed in a similar way to the analysis of a Purchase. 
The results show that all dead markings of an Authentication transaction repre- 
sent desired terminal states of the Authentication. Since a Deposit, Withdrawal 
and Refund use the same transaction procedure as a Purchase without delivery, 
the dead markings of each of them are a subset of those of a Purchase. This subset 
of dead markings does not have any trading role state information in the De- 
livery and the Payment-and-Delivery exchanges. A Value Exchange transaction 
involves two Payment exchanges and therefore has new dead markings concern- 
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Table 3. Statistics of SCO graphs for transactions in Configuration Set 1 



Configuration 


SCC Nodes 


SCC Arcs 


Terminal SCCs 


Time(sec) 


(Authentication, 1) 


276 


759 


4 


1 


(Purchase, 1) 


3695 


10021 


37 


28 


(Deposit, 1)/ 
(Withdrawal, 1)/ 
(Refund, 1) 


2465 


7021 


19 


16 


(ValueExchange, 1) 


2919 


8148 


25 


20 



ing transaction terminations in the second Payment exchange. Inspection of the 
dead markings for each of the above four Payment-related transactions shows 
that, there will not be any inventory problem for the Merchant, however, the 
non-refundable payment problem may still occur to the Consumer. 

Hence, we prove that Property 1 holds for an Authentication transaction, 
but does not hold for all Payment-related transactions. 



4.5 Absence of Livelocks 

To check whether IOTP transactions involve livelocks, the SCC graphs are gen- 
erated for the transactions with configurations in Configuration Set 1. A SCC 
graph has a node for each SCC and arcs which connect two different SCCs. 
The terminal SCC is a SCC without outgoing arcs. Table 3 lists the statistical 
information of the SCC graphs for transactions in Configuration Set 1. 

The comparison between Tables 1 and 3 shows that each transaction state 
space has the same number of nodes and arcs as its SCC graph. Therefore, each 
transaction state space is isomorphic to its SCC graph and contains no self- loops. 
This proves Property 2 for all configurations in Configuration Set 1. 

4.6 Absence of Unexpected Dead Transitions 

When the IOTP CPN model is executed, we expect transitions which model 
protocol operations that are not activated under certain configurations of IOTP 
to be dead. For example, each transaction page in the model is specific to the 
transaction indicated by its page name (see the Hierarchy page of the model 
in Fig. 2). Suppose that the model is executed for an Authentication transac- 
tion. Only two transaction pages, AuthTr_C and AuthTr_M. and their subpages, 
the six exchange level pages, Authenticatee, Authenticator, Cancellation_C, Can- 
cellation_NC, ErrHandling_C and ErrHandling_NC will be executed. The remaining 
transaction pages and exchange level pages will not be activated, and therefore 
all the transitions on these pages are expected to be dead. In a similar way, we 
can see which transaction pages and exchange level pages are activated for each 
of the other five transactions. From the transaction state space the dead transi- 
tions for each configuration in Configuration Set 1 are those expected, proving 
Property 3 for all configurations analysed. 
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5 Conclusions 

Based on the IOTP CPN specification in [14], we have analysed three desired 
properties of IOTP: 1) valid transaction termination; 2) absence of livelocks; and 
3) absence of non-executable protocol operations (indicated by unexpected dead 
transitions) . Inspection of the transaction termination property has revealed de- 
ficiencies in the current design of IOTP, where the Payment-related transaction 
fails to terminate correctly. The problems are: 1) the Merchant not being in- 
formed of transaction cancellation between Consumer and Payment Handler or 
Delivery Handler, which may cause an inventory problem for the Merchant (in 
a Purchase transaction); and 2) a transaction cancelled at the Consumer side 
only, which may introduce a non-refundable payment problem to the Consumer 
(in all Payment-related transactions). 

Future work will involve proposing solutions for the above problems, changing 
the CPN model accordingly, and re-analysing it to verify that the solutions work 
correctly. Also we would like to continue our work in [13] on proving that IOTP 
conforms to its intended service defined in [ 5]. 
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Abstract. E-Commerce systems have become ubiquitous. However, it 
is a challenge to create high quality e-commerce systems respecting time 
and budgetary constraints. In this paper, we present a life-cycle testing 
process for e-commerce systems by adapting OO-TTCN-3, an object- 
oriented extension of a formal test language TTCN-3, to enable the ef- 
ficient specification of tests in object-oriented, e-commerce development 
environments. This extension is meant to ease life-cycle testing, facili- 
tate test case reuse between different test phases, and provide a unified 
Abstract Test Suite (ATS) interface to test tools. A case study shows 
how to apply the approach to a typical e-commerce system based on 
a high-yield, risk-directed strategy. 



1 Introduction 

Web techniques have grown very fast in recent years. Electronic Commerce (E- 
Commerce) systems, which facilitate the conduct of business over the Internet 
with the assistance of Web techniques, have been adopted by more and more 
companies as the architecture of their enterprise information systems. It is a chal- 
lenge to build a quality e-commerce system under the constraints of time and 
budget. Software testing is an essential and effective means of creating quality 
e-commerce systems. 

Software testing is a life-cycle process which parallels the software develop- 
ment process [8, ]. Generally, a complete software testing life cycle includes 
the following phases: test planning, verification and validation (V&V) of system 
analysis and design (AD) models, unit testing, integration testing, functional 
testing, and non-functional system testing. In these testing phases, we need to 
build and test various AD models, as well as the implementation, by applying 
multiple testing methods and utilizing multiple testing tools. 

* This work was partially supported by Communications and Information Technology 
Ontario (CITO) in a collaborative project with IBM, and by Testing Technologies 
1ST GmbH. The authors are grateful for the comments of the anonymous refer- 
ees, which improved the paper considerably. 
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Life-cycle testing, however, does not guarantee testing software thoroughly. 
In the real world of software projects, software should be tested in a cost-effective 
way: executing a limited number of test cases, but still providing enough confi- 
dence. A high-yield, risk- directed test strategy introduced in [12] is a cost-effective 
approach of test case design: test cases that are high-yield (that have the highest 
probability of detecting the most errors) and high-risk-directed (that have the 
most serious consequences if they fail) are developed and executed with high 
priorities. 

In this paper, we propose a life-cycle e-commerce testing approach based 
on a high-yield, risk-directed strategy by specifying test cases at an abstract 
level in OO-TTCN-3. The paper is organized as follows. In section 2 we discuss 
briefly the nature and architecture of web applications, and discuss related work 
on web application modeling and testing. In section 3 we introduce a life-cycle 
testing approach, and propose a useful object-oriented extension to TTCN-3. 
In section 4 we present a case study in which we apply the proposed testing 
approach. In section 5 we present a summary and discuss possible future work. 

Web application, a term similar to e-commerce system, is also used in this 
paper. There is no essential difference between these two terms. Informally, we 
consider that e-commerce system is a term with broader scope than web appli- 
cation: an e-commerce system may consist of several relatively independent web 
applications. 

2 Testing E-commerce Systems: 

Background and Related Work 

2.1 The Nature and Architecture of Web Applications 

Generally, web applications are a kind of thin-client Client/Server (C/S) system. 
However, compared to traditional C/S software systems, web applications have 
natures which make them more complex to design and test: (1) server-based ap- 
plication architecture such that no special software or configuration are required 
on client side (2) navigation-based interaction structure (3) n-tiered system ar- 
chitecture such that the components of each tier may be distributed and run on 
heterogeneous hardware and software environments (4) independent of types, 
brands, and versions of web servers and browsers (5) the web server may con- 
currently process tens of thousands of requests from client applications (6) code 
contains a blend of object-oriented and procedure-oriented programming. 

Today, most e-commerce systems are running on the 4-tiered architecture, 
that is, client tier, web tier, business tier, and Enterprise Information System 
(EIS) tier. Each tier is built on component-based techniques. 

2.2 Web Application Modeling and Testing 

There has been much research into web application modeling and testing. 

UML (Unified Modeling Language) is suited to modeling web applications, 
but needs some extensions to describe web-specific elements. Some extensions to 
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UML were proposed in [7] to represent web-specific components, such as client 
pages, server pages, forms, hyperlinks, and Java Applets. The authors of [ 
discussed how to apply extended UML to build a business model, navigation 
model and implementation model. 

Several approaches have been proposed to support web application testing. 
In [18], an object-oriented architecture for web application testing was proposed 
which contains several analysis tools that facilitate the testing of web-specific 
components. In [3], the authors presented a testing methodology for web appli- 
cations based on an object-oriented web test model, which captures test artifacts 
from three different aspects: the object aspect, the behavior aspect, and the 
structure aspect. In [10], the authors proposed a definition of unit and integra- 
tion testing in the context of web applications. The testing approaches discussed 
above focus on testing web applications after they have been built. Alterna- 
tively, in [13], the authors presented a formal method which integrates testing 
into the development process as early as the system analysis and design phases. 
The paper demonstrated how to use the Specification and Description Language 
(SDL), Message Sequence Charts (MSCs), the Tree and Tabular Combined No- 
tation (TTCN), and industrial-strength system design tools such as Telelogic 
TAU to develop and test a CORBA-based e-commerce system. 

These testing approaches contributed to the improvement of web application 
quality. However, they only applied to part of development life-cycle: either in 
the analysis and design phases or the implementation phase. In addition, the test 
cases developed in a testing approach are written in a specific script language 
and depend on proprietary or specific industrial tools. These test scripts can not 
be reused by other testing approaches. In this paper, we intend to propose a life- 
cycle testing approach which leverages multiple testing methods in a life-cycle 
testing process. Furthermore, we integrate all the testing phases by specifying 
test cases on the abstract level with Object-Oriented TTCN-3. These abstract 
test cases can be easily reused in the whole testing process, and are independent 
of specific testing tools. 

3 A Life-Cycle Testing Approach with OO-TTCN-3 

3.1 A Life-Cycle Testing Process 

Life-cycle e-commerce testing is a process of applying multiple testing methods 
to AD models and implementations in different testing phases, with assistance of 
various test tools, as shown in Figure 1. In this process, we specify all test cases 
in OO-TTCN-3. The dashed lines in Figure 1 indicate the possible ATS reuse. 
The ATS expressed in OO-TTCN-3 provides a unified interface. This makes 
test scripts independent from specific test tools. This also facilitates ATS reuse 
between different test phases: e.g., test scripts for unit testing can possibly be 
reused by integration testing without any modification, and different test tools 
may be used for the unit testing and integration testing. 
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Fig. 1 . Life-cycle Testing Process Model with OO-TTCN-3 for E-Commerce Systems 

3.2 Introduction to TTCN-3 

TTCN-3 has been developed and standardized by ITU and ETSI (European 
Telecommunication Standards Institute) for general testing purposes. An ATS 
specified in TTCN-3 is independent of languages, platforms, and testing tools. 
TTCN-3 is built from a textual core notation on which several optional presen- 
tation formats are defined, such as the tree and tabular format (TFT) and the 
Graphical Presentation Format (GFT) [4, 5]. Complex distributed test behavior 
can be specified at an abstract level in TTCN-3 flexibly and easily in terms of 
sequences, alternatives, loops and parallel stimuli and responses. Practical appli- 
cations of TTCN-3 were introduced in [14, 2, 15, 16]. In addition, an extension 
for TTCN-3 were proposed in [2] to handle specific issues in testing real-time 
systems. 



3.3 Object-Oriented TTCN-3 

In this paper, we do not intend to make TTCN-3 fully object-oriented. Instead, 
our extension only focuses on specifying inheritance hierarchies and aggregation 
relationships between test modules. 



Inheritance When we test an object-oriented system, if an inheritance rela- 
tionship in the system is introduced during design in accordance with the Substi- 
tution Principle, an inheritance relation also will hold for the test cases for this 
inheritance hierarchy [11]. As shown in Figure 2, class B is derived from class 
A in accordance with the Substitution Principle, and TM_A and TM_B are test 
modules for class A and B, respectively. There exists an inheritance relation- 
ship between TM_B and TM_A. The allowed ways of introducing inheritance 
as required by the Substitution Principle, and corresponding test case design 
considerations are as follows [11]. 
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Fig. 2. Class Inheritance Hierarchy and Corresponding Test modules 



A new operation, say b_opl, is added to the interface of B and possibly 
a method is created to implement the operation. In this way, specification- 
based test cases will now be required for the operation in TM_B. If the 
operation has an implementation, implementation-based test cases need to 
be added to comply with coverage criteria. 

- If an operation in B, say a_opl which is inherited from A, has not changed 
in any way, either in specification or in implementation, the test cases for 
this operation in TM_A still apply to TM_B, which means the test cases do 
not need to be rerun in TM _B if they have passed in the execution of TM_A. 

- The specification of an operation in B, say a_op2 which is inherited from A, 
has changed. In this case, new specification-based test cases are required for 
the operation in TM_B, which will satisfy any weakened preconditions and 
check outputs for the new expected results from any strengthened postcon- 
ditions. The test cases for this operation in TM_A must be re-run. If the 
expected results need to be revised according to the strengthened postcon- 
dition, the test cases in TM_B need to be overridden. 

- An operation in B, say a_op3 which is inherited from A, has been overrid- 
den. In this case, all the specification-based test cases for the operation in 
TM_A still apply in TM_B. The implementation-based test cases need to be 
reviewed. Some test cases need to be overridden, and new test cases need to 
be added to meet the test criteria for coverage. 

In short, test cases in TM_A can be reused in TM_B. TTCN-3 provides 
a way to reuse definitions in different modules by using the import statement. 
However, as a procedure-oriented language, TTCN-3 is incapable of specifying 
the inheritance relationship between TM_A and TMJB. 

Therefore, we extend TTCN-3 with a fundamental object-oriented mecha- 
nism, namely inheritance (extend and override) , to make it capable of specifying 
derived test modules. The extension helps to specify the inheritance hierarchies 
in test modules clearly, and it eases the reuse of test case definitions in unit test- 
ing at the class level. For example, for a simple inheritance hierarchy shown in 
Figure 3, we can develop test cases based on the specification and implementation 
(if any) of an abstract class Account, and specify them in OO-TTCN-3 in test 
module Account Test, even before the creation of two subclasses: EXAccount and 
BankAccount. After the two subclasses have been designed and implemented, the 
test cases in Account Test are ready to be reused for test module EXAccount Test 
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Fig. 3. Partial Class Diagram for Account, EXAccount and BankAccount 



and Bank Account Test which are inherited from Account Test. In addition, if any 
subclass is derived from the class Account in the next development iteration, 
the test module for the new subclass can also benefit from the existing testing 
module hierarchy. 

In section 4.3.3, we show how to use OO-TTCN-3 to specify a derived test 
module. 



Extending TTCN-3 with an Inheritance Mechanism To extend TTCN- 
3 for specifying inheritance relationships between test modules, we investigate 
which elements in a test module are likely to be reused, and which elements can 
be extended or overridden in its derived test module. The result is shown in 
Table 1. From the table, we see that almost all of the elements can be reused 
directly, and some elements can be reused by means of an extend or override 
mechanism. 



Table 1 . Element reuse in a test module in TTCN-3 



Elements 


Reuse 


Extend 


Override 


Definition 


Type 

Definition 


Built-in 


N 


N 


N 


User-defined 


Y 


N 


N 


RP Signature 


Y 


N 


Y 


Test Data 


Constant 


Y 


N 


N 


Data Template 


Y 


N 


N 


Signature Template 


Y 


N 


Y 


Test 

Configuration 


Communication Port 


Y 


Y 


N 


Component 


Y 


Y 


N 


Behavior 


Function 


Y 


N 


Y 


Named Alternatives 


Y 


N 


Y 


Test Case 


Y 


N 


Y 


Control 






N 


N 


N 
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Fig. 4. Aggregation Relationship between Test Modules 



We extend TTCN-3 by adding two key words: private and public, to indicate 
if an element is ready to be reused in a derived test module, and we assume that 
if an element is not specified explicitly with the key word private, the element 
is defined to be public by default. We also propose to add a key word extends , 
which is used to specify that a test module is inherited from another test module. 
The modified TTCN-3 syntax in BNF form is as follows (the sequence numbers 
correspond to those defined in Annex A in [4]): 

1. TTCN3Module : : =TTCN3ModuleKeyword TTCN3ModuleId [extends TTCN3ModuleId] 

BeginChar 

[ModuleDef initionsPart] [ModuleControlPart] 

EndChar 

[WithStatement] [SemiColon] 

52. PortDefBody: :=PortTypeIdent if ier [extends PortTypeldentif ier] PortDef Attribs 
73. ComponentDef : : =ComponentKeyword ComponentTypeldentif ier 
[extends ComponentTypeldentif ier] 

BeginChar [ComponentDef List] EndChar 



Aggregation There may also exist an aggregation relationship between test 
modules, e.g. between test modules for functional testing and those for unit 
testing. In Figure 4, a functional test scenario derived from the User Login use 
case consists of four steps. Each step corresponds to one test case defined in 
the test module for unit testing. The functional test scenario can be realized by 
executing these test cases. This relationship can be expressed as an aggregation 
relationship in UML. In section 4.5, we show how to specify a test module for 
a functional test scenario by reusing test cases defined in unit testing. 



4 Case Study 

In this section we present part of a case study in which we apply our life-cycle 
testing approach with OO-TTCN-3 to a typical e-commerce system based on 
a high-yield, risk-directed strategy. The complete case study can be found in [17]. 

4.1 Overview of EX System 

The EX system is an on-line currency exchange system which acts as a broker to 
provide customers the best exchange rate between Canadian Dollars (CND) and 
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Test Scenario 


Yield 


Risk 


Priority 


[TS001] 

Pre-conditions: 

1. Login page is displayed 

2. User account is not locked 
Action: 

Enter valid User ID and Password, click Login button 

Post-conditions: 

Web page with account infoimation is displayed, and a 
session is created 


Low 


Medium 


Low 


[TS007] 

Pre-conditions: 

1. Login page is displayed 

2. User account is locked 
Action; 

Enter valid User ID and Password, click Login button 

Post-conditions: 

1 . Web page with account locked message is displayed 

2. User account is locked 


High 


High 


High 



Fig. 5. Test scenarios for the User Login use case 



U.S. Dollars (USD) among its linked banks at remote sites. The entire EX system 
can be divided into three subsystems: EX web application subsystem (EAS), 
bank subsystem (BS) , and post office subsystem (PS) . EAS obtains quotes from 
banks and presents the best one to web clients (WC). 



4.2 Verify and Validate the System Analysis and Design Models 

During the system AD phases, the AD models, e.g., UML use cases, need to 
be verified and validated. For example, guided inspection can be used to verify 
the use case model for correctness, completeness and consistency [22]. Then, 
test scenarios can be developed from the verified use cases: one is the normal 
scenario which is considered low-yield and low-risk/medium-risk; one or more 
are for alternative and exceptional scenarios which are considered high-yield 
and high-risk/medium-risk. Figure 5 lists part of the test scenarios derived from 
the User Login use case. Some design models, e.g., activity diagrams, can be 
used to analyze and improve the coverage of the test scenarios [17]. 

The test scenarios above can be specified in GFT, as shown in Figure 6. 
These GFTs can be used to validate whether the design models conform to the 
requirements, e.g. comparing them with the MSCs created in the development 
process. 

After the GUI design has been done, test cases can be developed from test 
scenarios and the GUI design. The development of high-yield test cases consists 
of three basic steps: (1) Partition input conditions into equivalence classes. (2) 
Create test data based on boundary- value analysis. (3) Design test cases to cover 
all test scenarios [17]. These test cases then are ready for functional testing. 

4.3 Unit Testing 

The unit testing level corresponds to the n-tier architecture of web applications: 
client tier testing, web tier testing, business tier testing, and EIS tier testing 
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Fig. 6. Test Scenario 1 & 7 in GFT 



(which we will not discuss in this paper) . This is because each tier is a relatively 
independent set of components. The techniques used with these components are 
similar in the same tier, but may be different in different tiers. Also, each tier 
has different responsibilities. 



Client Tier Typical components in the client tier are html files, scripts embed- 
ded in an html file, and Java Applets. They run on the client side, usually within 
the content of a browser. From a functional perspective, common testing activ- 
ities in the client tier include validating that every hyperlink in an html file is 
valid and that scripts and applets act as expected. Testing models based on the 
analysis of data flow and control flow of source code can be used to derive test 
cases [3]. The following TTCN-3 script demonstrates how to check the validity 
of a hyperlink. 

module hyperlinkCheck-C 
modulepar {charstring testtype}; 

type record url {char string protocol, charstring host, char string portNum, 
charstring path} 

template url hyperlink_ index := {protocol :=https://, host :=www. site. uottawa.ca, 
portNum : = : 1 180 , path : =ex/index . html} 
template charstring status_ok := 200; 
template charstring status_timeout := 408; 

type port hyperlinkPortType message {out url; in charstring} 
type port mCPType message {in verdicttype} 
type port pCPType message {out verdicttype} 

type component hyper linkComponent {port hyperlinkPortType hyperlinkPort ; 
port pCPType CP} 

type component mtcComponent {port mCPType CP; 
port hyperlinkPortType hyperlinkPort; 
var integer activePTCs := 0;} 
type component TSI {port hyperlinkPortType hyperlinkTSI} 
function hyperlink_check (in url hyperlink, mtcComponent theSystem) 
runs on hyper linkComponent { 
map (self : hyperlinkPort , theSystem: hyperlinkPort) ; 
hyperlinkPort . send (hyperlink) ; 
alt { 

[] hyperlinkPort .receive (status_ok) {setverdict (pass)} 

[] hyperlinkPort .receive (status_timeout) {setverdict (inconc)} 

[] hyperlinkPort .receive () {setverdict (fail)} } 

CP . send(getverdict) ; } 

testcase hyper link_tc (in url hyperlink, integer loops, out integer passedTCs, 
integer failedTCs , integer inconcTCs)runs on mtcComponent system mtcComponent{ 
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var verdicttype theVerdict; 
var hyper linkComponent theNewPTC [loops] ; 
for (i :=1 ; i<=loops ; i :=i+l) { 
theNewPTC [i] := hyper linkComponent . create ; 
activePTCs := activePTCs + 1; 
connect (mtc : CP , theNewPTC [i] : CP) ; 

theNewPTC [i] . start (hyperlink_check (hyperlink, system)); } 
while (activePTCs > 0) { 

CP. receive (verdicttype :?)-> value theVerdict; 
activePTC := activePTC - 1; 
setverdict (theVerdict) ; 

if (theVerdict == pass) { passedTCs := passedTCs + 1; } 
else if (theVerdict == fail) { failedTCs := failedTCs + 1; } 
else if (theVerdict == inconc) { inconcTCs := inconcTCs + 1; } } 
all component .done; } 

function basicFunctionality () return verdicttype { 
var verdicttype localVerdict ; 
var integer nrP := 0, nrF := 0, nrl := 0; 

localVerdict := execute (hyperlink_tc(hyperlink_index, 1 ,nrP,nrF,nrI) ) ; 
return localVerdict; } 
control { 

var verdicttype overallVerdict ; 
if (testtype == basicFunctionality) { 

overallVerdict := basicFunctionality () ; } } } 



Web Tier Components running in the web tier are JSP files, Java Servlets, and 
CGI programs etc. Web components are also identified by URLs, in the same way 
as html files, but run on the server side. In addition, servlet and CGI programs 
may utilize parameters wrapped in an HTTP request. These components are 
usually referred to as server pages, while html files are referred as client pages. 
Test modules in TTCN-3 for server pages are similar to those for client pages, 
but with a significant difference: using procedure-based ports which are based on 
a synchronous communication mechanism to specify procedure calls in remote 
entities, instead of message-based ports which are based on asynchronous mes- 
sage exchange. The following code segment shows how to specify a test module 
for testing Login Servlet by using a procedure-based port: 



signature loginServlet (in url url_loginServlet , charstring ID, 
char string password) return boolean exception (reasonType) ; 
template loginServlet validLogin := {url_loginServlet := url_login_template , 
ID := C001, password := C001} 
type port loginPortType procedure -[out loginServlet} 



Business Tier The objects in the business tier are used to implement the busi- 
ness logic of web applications. The objects can be represented by class diagrams, 
possibly with constraints written in Object Constraint Language (OCL). Test 
cases can be derived from the class diagrams and constraints. Often, there ex- 
ists an inheritance relationship between these test cases, as we have discussed in 
section 3.3.1. Test modules for specifying these test cases can be specified in OO- 
TTCN-3, which can specify the inheritance relationship between test modules 
appropriately. 

In the EX system, Account is an abstract class (see Figure 3). It contains 
two attributes: accNum and user. One of the methods defined and implemented 
in the class Account is getAccountNoQ, which returns the account number of 
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Fig. 7. Partial Object Relation Diagram for EX system 



the current user. Two subclasses, BankAccount and EXAccount, are derived 
from Account. BankAccount is used to describe the attributes and behaviors of 
bank accounts. EXAccount is used to describe the accounts in the EX system. 
The signatures and implementations of getAccountNoQ do not change in the 
two derived classes. Therefore, test cases developed for getAccountNoQ can be 
reused by the test modules for BankAccount and ExAccount. In addition, we 
only need to run the test suites once, either in the test module for BankAccount 
or in the module for EXAccount, to validate the method in the three classes. 
This also avoids testing the abstract class Account, which cannot be instantiated 
and is difficult to test directly. The following is a code segment which shows how 
to specify the test modules in OO-TTCN-3: 

module AccountTest { 

signature Acc_constr (in charstring AccNum, charstring user)exception(charstring) ; 
signature getAccountNo () return charstring exception (charstring) ; 
testcase getAccountNo_tc() runs on mtcType system mtcType{ . . . } } 
module BankAccountTest () extends AccountTest { 
control {execute (get AccountNo_tc ()) ;} }- 



4.4 Integration Testing 

The purpose of integration testing is to make sure all components of a soft- 
ware system work together properly. ATS defined for unit testing can be reused 
directly for integration testing. Figure 7 is the partial ORD (Object Relation 
Diagram) for the EX system. The test module LoginServletTest defined for web 
tier testing is ready for integration testing, which includes the components login 
server page, LoginServlet servlet, logonSuccess server page, and EXBean, and 
interactions between these components. 
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4.5 Functional Testing 

The purpose of functional testing is to ensure the behaviors of a software system 
meet its functional requirements. Test scenarios in GFT developed at the sys- 
tem analysis and design phases can be used to generate test cases for functional 
testing. Actually, a bidirectional mapping between the core language and GFT 
is defined in [5], which makes it is possible to generate test scripts in core lan- 
guage from the scenarios in GFT automatically, or vice-versa, given specific tool 
support. On the other hand, test modules in TTCN-3 can be built manually. 
We can specify test cases developed in the system AD phases in TTCN-3. In 
addition, test scripts produced in unit testing can be reused in functional testing. 
The following is a code segment to test User Login functionality, which utilizes 
part of the definitions from test modules hyper linkCheck and LoginServlettest. 

function validLoginO return verdicttype { 

localVerdict : =execute (hyperlinkCheck . hyperlink_t c (hyperlink_index , 1 , 0 , 0 , 0) ) ; 
if (localVerdict != pass) {return localVerdict;} 
localVerdict : = execute (hyperlinkCheck . hyperlink_t c (hyperlink_login , 1 , 0 , 0 , 0) ) ; 
if (localVerdict != pass) {return localVerdict;} 
localVerdict := execute (LoginServletTest . validLogin_tc()) ; 
if (localVerdict != pass) {return localVerdict;} 

localVerdict : =execute (hyperlinkCheck . hyperlink_tc (hyperlink_logout , 1 , 0 , 0 , 0) ) ; } 



4.6 Non-functional System Testing 

Non-functional system testing is the process of testing an integrated software 
system to verify that the system meets its specified non-functional requirements. 
Test cases for non-functional system test cases, such as performance tests, can be 
specified in TTCN-3. Test scripts developed in the previous testing stages, such 
as functional testing, may be reused for non-functional testing. The following 
is an example of performance testing: adding a function in the hyperlinkCheck 
test module to simulate 1000 times of clicking on index.html, and then observing 
how many requests timeout or fail: 

function perf ormanceTestingO return verdicttype { 

localVerdict := execute (hyper link_tc (hyper link_ index, 1000, nrP,nrF, nrl) ) ; } 



4.7 Concrete Requirements and Results 

The above abstract test suite can be executed after transforming it into exe- 
cutable code in an implementation language such as Java. This has been achieved 
by using one of the many commercially available TTCN-3 tools, like in our case, 
TTthree [6]. After that the actual execution of this code can be performed us- 
ing a runtime environment like TTman [6] that allows a user to select a given 
test case to be executed. However, the abstract test suite can be executed only 
after organizing some adapter and coding/decoding code to transfer data from 
an internal representation to the real world representation. This can be achieved 
by using ETSI standard tri and tci classes interfaces and a set of APIs. Sample 
code can be viewed at www.site.uottawa.ca/ bob/ECTesting. Once the adapter 
and codec code compiled, they can be fed to the muTTman test case manager 
that shows a list of test cases and upon execution a test case execution trace as 
shown in Figure 8. 
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Fig. 8. Test Case Execution Result 



5 Summary and Future Work 

In this paper, we proposed an approach which realizes a life-cycle test process 
for e-commerce systems by specifying the ATS in OO-TTCN-3. The approach 
facilitates the reuse of test scripts. It also provides a unified and standard ATS 
interface to test tool vendors. This has significant potential to attract more 
support from the IT industry. 

Making a complete object-oriented extension to TTCN-3 would be quite 
complex. In this paper we present a preliminary such extension. A formal de- 
scription of this extension and a prototype tool that supports OO-TTC-3 will 
be considered in future work. 
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Abstract. We present a generic formal framework to specify e-com- 
merce systems. Specifically, we introduce a formalism to represent the 
behavior of the agents involved in the system. We will concentrate only 
on the high level behavior, that is, the one related to the economic perfor- 
mance of the agents. Finally, we apply our framework to the specification 
of the e-commerce system Kasbah. 



1 Introduction 

Among those areas where computers are yielding a higher impact during the last 
years we may remark electronic commerce. In fact, commerce activities under 
electronic, computer, and telecommunication support have several advantages 
with respect to traditional commerce. Nevertheless, e-commerce applications are 
usually very complex. Thus, it is hard to ensure reliability and correctness. Ac- 
tually, e-commerce applications use to be distributed environments consisting 
of a big amount of heterogeneous components, being each of these components 
eventually depending on a different party. Besides, e-commerce applications usu- 
ally have repercussions on the private patrimony of the users, either by conduct- 
ing the user decisions through recommendations or by performing transactions 
in his name. Therefore, the success of an e-commerce platform dramatically de- 
pends on the confidence the users have on it. So, a key issue in the current and 
future development of e-commerce systems is the introduction of techniques to 
validate their behavior so that all users can trust the platform. 

An aspect that has attracted a lot of attention is the communication valida- 
tion of e-commerce protocols. Transactions in e-commerce environments involve 
a lot of communications, being critical in the sense that any transmitted message 
must conform to the meaning the emitter initially gave to it. Only in this case, 
the actions of a user will depend on his own responsibility, which is a requirement 
in any economic environment. Thus, typical problems to be issued are authen- 
tication, privacy, integrity of data, and (no) repudiation (see e.g. [L, 2]). In this 
line, some formal approaches have been proposed to check the behavior of some 
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e-commerce environments. These solutions focus on formalizing and studying the 
communication protocols used in the corresponding e-commerce application. In 
fact, they are not specific of e-commerce domains, as they are used in the same 
way when any other communication protocol is validated, that is, they deal with 
a part of the low-level behavior of an e-commerce application. Thus, they can- 
not be considered as specific e-commerce validation formal techniques. We think 
that the e-commerce field contains enough specific aspects to deserve its own 
validation techniques and tools to efficiently deal with its intrinsic features. 

The aim of this paper is to develop a specific framework to specify and check 
the correctness of the high-level part of e-commerce applications. To become 
more definite, we introduce a formalism to specify the behavior of autonomous 
commerce agents. In fact, autonomous commerce agents are one of the most 
interesting and challenging technologies in e-commerce (see e.g. [6, 14, 11, 8]). 
They are autonomous entities that perform transactions in the name of their 
respective users. Their high-level specification can be defined as “get what the 
user said he wants and when he wants it”. We will consider that the specific 
preferences of the users will conform a specification. 1 Therefore, we will need 
a proper formalism to represent this kind of specifications, that we will call 
utility state machines and were introduced in a slightly different form in [13]. 

In terms of related work there are innumerable papers on e-commerce in 
general or on topics as e-commerce systems/ arquitectures and agent-mediated e- 
commerce. This number strongly decreases when considering formal approaches 
to e-commerce. In this case we may mention [9, 10] where, taking as basis the 
language PAMR [12], process algebras to specify e-barter systems (that is, a re- 
stricted notion of e-commerce) were introduced. 

The rest of the paper is structured as follows. In Section 2 we present the 
formalism that allows us to specify autonomous commerce agents. In Section 3, 
we define how agents can be combined to build systems of agents. In Section 4 
we apply our formal framework to the Kasbah system. Finally, in Section 5 we 
present our conclusions and some lines for future work. 



2 Utility State Machines 

In this section we present the formalism we will use to specify our autonomous 
exchange agents. As we said in the introduction, our validation methodology will 
focus on determining whether an implementation fulfills the desires of the users 
in terms of gained utility. Nevertheless, we will not be interested in how the utility 
is gained. So, the formalism will not include details about how private data are 
encrypted, how to find potential customers, how to estimate the confidence level 
on a given vendor, or what is the specific strategy to compete with other agents. 
Instead, we will check whether the transactions are performed according to the 
preferences of the users. Obviously, the performance of agents will be influenced 



1 In this paper we do not deal with how agents infer the exact desires of the users 
since this goes beyond the scope of the paper (see e.g. [4, 5, 7]). 
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by low-level details, but this influence will be considered only on the basis of its 
consequences, that is, on the basis of the high-level behavior. 

The objectives of the users may be different according to the situation. In an 
e-commerce environment the objectives are measured in terms of the obtained 
resources. Users will have different preferences and the first step to construct the 
specification of the corresponding agent consists in expressing these preferences. 
The preferences of the user in a given moment will be given by its utility func- 
tion. Utility functions associate a value (a utility measure) with each possible 
combination of resources a user could own. 

Definition 1. We consider R + = {x £ R|x > 0}. We will usually denote vectors 
in R™ (for n > 2) by x, y, . . . We consider that 0 denotes the tuple having all 
the components equal to zero. Given x € R n , x,; denotes its i-th component. We 
extend some usual arithmetic operations to vectors. Let x,y £ R m . We define 
x + y = (xi + yi, . . . ,x n + y n ) and x ■ y = (xi • yi, . . . , x n ■ y n ). We write x < y 
if for any 1 < i < n we have x < yi. 

Let us suppose that there exist n different kinds of resources. A utility func- 
tion is any function / : R” — > R + . □ 

Intuitively, if / is a utility function then /(x) > f(y) means that x is preferred 
to y. For instance, if the resource x\ denotes the amount of apples and X 2 denotes 
the amount of oranges, then /(x i, X 2 ) = 3 • x\ + 2 • X 2 means that, for example, 
the user is equally happy owing 2 apples or 3 oranges. Let us consider another 
user whose utility function is f(x\,x 2 ) = x\ + 2 • X 2 - Then, both users can make 
a deal if the first user gives 3 oranges in exchange of 4 apples: After the exchange 
both users are happier. Let us suppose now that X 2 represents the amount of 
money (in euros) . In this situation, the first user would be the customer while the 
second one might represent the vendor. Let us remark that utility functions allow 
a great expressivity in preferences. For instance, /(x 1 ,^ 2 ) = x\ ■ X 2 represents 
a utility function denoting that variety is preferred. A usual assumption is that no 
resource is a bad, that is, A f( x ^—’ Xn ) > q for any Xi, ... ,x n € R and 1 < i < n. 
This requirement does not constrain the expressive power of utility functions, 
as the existence of any undesirable resource can be always expressed just by 
considering another resource representing the absence of it. 

In order to formally specify autonomous commerce agents we have to rep- 
resent the different objectives of the corresponding user along time. Thus, our 
formalism will provide the capability of expressing different utility functions de- 
pending on the situation, represented by the current state. Besides, objectives, 
represented by utility functions, will change depending on the availability of re- 
sources. These events will govern the transitions between states. Our formalism, 
that we call utility state machines, is indeed an adaption and extension to our 
purposes of the classical notion of extended finite state machines (EFSM). We will 
be able to deal with time as a factor that influences the preferences of users, 
either by affecting the value returned by a given utility function (e.g. the inter- 
est in a given item could decay as time passes) or by defining when the utility 
function must change (e.g. an old technology is considered obsolete and it is no 
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longer interesting). Besides, time will affect agents in the sense that any negative 
transaction will imply a deadline for the agent to retrieve the benefits of it. In 
fact, gaining profit in the long run may sometimes require to perform actions 
that, considered in the short term, are detrimental. Thus, time will be used to 
check whether the transaction was beneficial in the long term. In addition, time 
will appear as part of the freedom that specifications give to implementations: 
It does not matter whether an agent immediately performs a transaction as long 
as its decision is useful to improve the utility in the long term. 

Definition 2 . We say that the tuple M = ( S,Si n ,V,U,at,mi,T ) is a utility 
state machine , in short USM, where we consider that 

— S' is a set of states. 

— Si n G S is the initial state of M. 

— V = (t,x i, . . . , x n ) is a tuple of variables, where t represents the time elapsed 
since the machine entered the current state and x\ , . . . , x n represent the 
resources that are available to be traded in the e-commerce environment. 

— U : S — > (R " +1 — > R + ) is a function associating a utility function with 
each state in M. 

— at is the amortization time. It denotes the maximal time M may stay without 
retrieving the profit of the negative transactions that were performed in the 
past. 

— mi is the maximal investment. It denotes the maximal amount of negative 
profit the machine should afford. 

— T is the set of transitions. Each transition is a tuple (s, Q, Z, s'), where 
s,s' € S are the initial and final state of the transition, Q : R " +1 — > Bool 
is a predicate on the set of variables, and Z : R™ — > R" is a transformation 
over the current variables. We require that for any state s there do not 
exist two different transitions t\,t2 G T, with t\ = (s,Qi, Zi, sf) and t,2 = 
(s, Q2, Zi, S2), and a tuple r such that both Qi(r) and Q 2(E) hold. 



□ 

We can consider environments where the resources increase/decrease as a re- 
sult of the agent activities. These modifications represent the decision of the user 
to introduce new resources in the market or to take away some of them. Both 
activities are accounted for by the Z functions appearing in transitions. Besides, 
let us remark that available resources and time influence the conditions required 
to change the state of the machine. This is taken into account by the Q func- 
tions appearing in transitions. Let us also note that in these constraints we may 
also consider the time previously consumed. In fact, we could use an additional 
abstract resource to accumulate the time consumed in previous states. 

It is worth to point out that the set of transitions T does not include the 
complete set of transitions the specification will allow real agents to perform. 
Some additional transitions must be considered: transactions and passing of time. 
The former will be used to denote the transactions agents will be allowed to 
perform. These transactions will include some simple constraints that allow us 




34 



Ismael Rodriguez et al. 



to avoid that an agent gives more resources than those actually owned, or to avoid 
giving resources if the amount of value lost in previous negative transactions, and 
not retrieved yet, is too high. Passing of time denotes the free decision of agents 
to idle. We consider two constraints on passing of time. First, an agent should 
not let the time pass so that previous negative transactions are not retrieved 
before their deadlines. Second, time conditions may trigger the modification of 
the state of an agent. Thus, in the exact time it happens, and before the passing 
of time action continues, the transition between states will be performed. Given 
a USM M, both transaction and time consumption transitions may be implicitly 
inferred from the definition of M. We will give the formal representation in the 
forthcoming Definition 5. Next we introduce the notion of configuration, that is, 
the data denoting the current situation of a USM. A configuration consists of the 
current state, the current values of the variables, and the pending accounting of 
the machine. 

Definition 3. Let M — (S, Si n ,V,U, at,mi,T) be a USM. A configuration of M 
is a tuple ( s,r,l ) where 

— s £ S is the current state in M, 

— f = (u, r-[ ,. . . , r n ) S R™ +1 is the current value of V, and 

— I = [(pi, ei), . . . , (p m , e m )] is a list of pairs (profit, time) representing the list 
of pending accounts. 



□ 

For each pair (p, e) € l we have that p represents a (positive or negative) 
profit and e represents the expiration date of p, that is, the time in which a profit 
greater than or equal to —p must be retrieved, in the case that p is negative, 
or the time in which p will be considered a clear profit if no negative profit is 
registered before. In order to explain the main characteristics of our framework, 
we will consider a simple (but illustrative) running example where some kids 
engage in the complicated world of becoming entrepreneurs. 

Example 1. Let us suppose that little Jimmy wants to sell lemonade in the mar- 
ket of his town. We will construct a USM J = ( S , s» n , V, U, at, mi, T) to represent 
the economic behavior of Jimmy. The tuple of variables V = ( t,l,d,s,m ) con- 
tains a value denoting time (t) and the amount of each resource: lemons (l), 
lemonades (d), selling licenses (s), and money (to). 

This USM is depicted in Figure 1. The initial state si represents a situation 
where Jimmy has no license to sell lemonade in the market. Unfortunately, all 
stands in the market are occupied. So, Jimmy has to buy it from another vendor. 
The utility function in si is given by U(s i)(r) = 10 • s + m, that is, Jimmy 
would pay up to $10 for a selling licence. Besides, lemons and lemonades are 
irrelevant at this preliminary stage. There are two possibilities for leaving the 
state .Si . On the one hand, if a week passes and Jimmy has not bought the 
selling license yet, then he will raise his effort to get the license. The transition 
trani = (s i, Q 2 , -Z 2 , S 2 ), where Q 2 (t,r) = (t = 7) and ^(r) = r, leads Jimmy to 
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si = Initial state 

52 = No license after one week 

53 = Jimmy has a license 

54 = Jimmy gives up 
tran.Q S5 = Jimmy is in business 



Fig. 1 . Example of USM: Jimmy’s business 



the new state. In state S2 we have U(s 2 )(f) = 20-s+?n, which denotes that Jimmy 
would pay now up to $20. On the other hand, if Jimmy gets the license then 
the transition tran 2 = (si, Q3, Z3, S3), where Q^(t,r) = (s = 1) and Z^{f) = 
(/, d, s — 1, to), leads him to S3. The function Z 3 represents that Jimmy will take 
away the license from his trading basket because he wants to keep it for himself. 
The utility function in S3 is represented by U(s3)(r) = 0.2 ■ l + m. This means 
that Jimmy wants to stock up with lemons to make lemonades. He will pay up 
to 20 cents for each lemon. 

If Jimmy is in state S2 then there are two possibilities as well. If another week 
elapses and Jimmy remains with no license then he gives up his project. This 
is denoted by the transition tran 3 = (S2, Q 4 , Z 4 , S4), where Qi(t,r) = (t = 7) 
and Zi(r) = (0,0, 0,0). The function Z 4 denotes that all resources are taken 
away from the trading environment. Hence, U(s 4 )(r) is irrelevant. The second 
possibility happens if Jimmy finally gets his license. In this case, the transition 
tran 4 = (s 2, Q 3, Z 3 , S3), where Q 3 = Q 3 and Z 3 = Z 3 , leads him to S3. 

We suppose that Jimmy uses 3 lemons for each lemonade. Thus, when Jimmy 
is in the state S3 and stocks up with 12 lemons then he makes 4 lemonades. This is 
represented by the transition tran 5 = (S3, Q 5 , Z5, S5), where Q4(t,r) = (l = 12) 
and Z^if) = (l — 12, d+ 4 ,s,to). In the state S5, Jimmy wants to sell his new 
handmade lemonades. The utility function U (.S5) (r) = 2 -d+m means that he will 
sell lemonades for, at least, $2. Finally, when lemonades run out, Jimmy thinks 
again about stocking up with lemons. So, the transition tran% = (S5, Qq,Zq, S3), 
where Qe{t,r) = (d = 0) and ^(r) = (r), moves Jimmy back to S3. 

A possible initial configuration of J is (si, (0, 0, 0, 0, 50), [ ]), which means 
that Jimmy begins his adventure with $50 and without pending accounts. □ 

Next we present some auxiliary definitions. First, we define the maximal time 
a USM is allowed to idle. Intuitively, this limit will be given by the minimum be- 
tween the minimal time in which the machine has to change its state and the 
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time in which the oldest pending account expires. If the minimum is given by 
the second value then we will use two auxiliary predicates to denote two special 
situations. The first predicate holds if an old positive profit expires at its amorti- 
zation time. In this case, the profit will be considered clear , since it has not been 
used to compensate any subsequent negative profit. The second one holds in the 
opposite case, that is, an old negative profit expires without being compensated 
before. This case denotes an undesirable situation in which the corresponding 
agent does not not fulfill its economic objectives. Let us note that even though 
this situation will be produced according to the behavior specified by a USM, it 
will be convenient that the implementation does not show such a behavior, since 
it is contrary to the economic objectives of the agent. Therefore, that informa- 
tion will have a special relevance to assess whether an implementation fulfills 
the requirements imposed by a specification. After introducing these predicates, 
we will present how the list of pending accounts must be updated when a new 
transaction is performed. If the sign of the new transaction coincides with those 
of the listed transactions (that is, either all of them are positive or all of them are 
negative) then this transaction will be added to the list. Otherwise, the value of 
the new transaction will compensate the listed transactions as much as its value 
can, from the oldest transaction to the newest. Finally, we will define how to 
add the profit accumulated in the list of pending accounts. 

Definition 4. Let M = (. S,Si n ,V,U,at,mi,T ) be a USM and c = ( s,r,l ) be 
a configuration of M, with r = (it, rq, . . . , r n ) and l = [(pi, ei) , . . . , ( p m , e m )]. The 
maximal waiting time for M in the configuration c, denoted by MaxWait(Af, c), 
is defined as 

min{ei, min{u / | 3(s, Q, Z, s") £ T : u 1 > u A Q(u', rq, . . . , r n ) = True}} 

If ei is actually the minimal value and pi > 0 then we say that M per- 
forms a clear profit, which is indicated by setting true the auxiliary condition 
ClearProf it(M, c). On the contrary, if ei is the minimal value and pi < 0 then 
we say that M fails its economic objective, which is indicated by setting true the 
auxiliary condition TargetFailed(Af, c). 

The update of the list of pending accounts l with the new profit a, denoted 
by Update)/, a), is defined as: 



Update)/, a) 



[(a, at + «)] 

/ H |-[(u, at + u)] 
(pi + a, ei) : l' 
Update(/',pi + a) 



if / = [] 

if / = (p 1 ,e 1 ):/ / A ^>0 

if l = (p 1 ,e 1 ):V A ^<0 A 2i±£> 0 

if Z = Cp 1 ,e 1 ):/ / A ^<0 A ^<0 



Finally, the accumulated profit 
Accumulated)/), is defined as 



of a list of pending accounts /, denoted by 



Accumulated)/) 



f0 if / = [ ] 

) p + Accumulated)/ 7 ) if / = (p,e) : l ' 



□ 
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Let us note that profits in any (non-empty) list of pending accounts are 
either all positive or all negative. In the definition of Update, conditions such as 
^ > 0 denote that n and m have the same sign. As we said before, if a (i.e. the 
new profit) has the same sign as (all) the profits in the list (e.g. the sign of p\) 
then the new transaction is added to the list. On the contrary, if both signs are 
opposite then a compensates the oldest profit pi as much as its value can. In 
this case, if Pl+a > 0 then the absolute value of a is lower than the absolute 

pi — 

value of pi . So, a does not completely compensates pi. If < 0 then we have 
the opposite situation, that is, p\ is completely eliminated and the remainder 
of a is recursively applied to the rest of the list. We have used a functional 
programming notation to define lists: [ ] denotes an empty list, l ++1' denotes 
the concatenation of the lists l and l', and x : l denotes the inclusion, as first 
element, of x into the list l. 

Example 2. Let us revisit Example 1. After a month, let us suppose that Jimmy 
is in configuration (s 3 , (31, 0,4, 0, 8.50), [ ]). Besides, let us suppose that Jimmy 
accepts payments for the lemonade in instalments. Today, Timmy consumes 
a lemonade at $2 but pays $1 as down payment. Besides, the next day Johnny 
consumes a lemonade at $2 and pays only $0.50 as deposit. Let us suppose 
that the amortization time of Jimmy is a week. Then, a possible configuration 
for Jimmy is (S3, (32,0, 2, 0, 10), [(— 1, 38), (—1.50, 39)]). At this time, Mr. Brown 
buys a lemonade, paying cash, for $3.50. Then, the new configuration for Jimmy 
is (s 3 , (32, 0,1, 0,13.50), [(-1,39)]). □ 

Given a USM M, an evolution of M represents a configuration that the USM can 
take from a previous configuration. Formally, evolutions are tuples ( c,d ,td)K 
where c and c' are the previous and new configurations, respectively, tc is the 
time consumed by the evolution, and K £ {a, /3, /3', 7} is the type of evolution 
( changing the state , passing of time, passing of time with failure, and performing 
a transaction) . The difference between [3 and (3 ' transitions is that in the second 
case the agent fails its economic objectives since a past negative profit expires 
at its amortization time. 



Definition 5. Let M = (. S,Si n ,V,U,at,mi,T ) be a USM and c = (s,r,l) be 
a configuration of M, with r = (u, ri, . . . , r n ) and l = [{pi, ei), . . . , (p m , e m )\. An 
evolution of M from c is a tuple (c, d , td)K where d = {s' , r' , V), K £ {a, (3, f3' , 7} 
and tc £ ft + are defined according to the following options: 



(1) {Changing the state ) If there exists {s,Q, Z, s") £ T such that Q(r) holds 
then K = a, tc = 0, s' = s" , and r' = (0, r^, . . . , r' n ), where {r' x , . . . , r' n ) = 
Z{n , . . . ,r„) and V = [{pi,ei -u),..., { p m ,e m - u)]. 

(2) {Passing of time) If the condition of (1) does not hold then for any tr £ ]R + 
such that 0 < tr < MaxWait(M, c) — u, we have tc = tr, s' = s, r' = 
{u + tr,r 1 , , r n ), and l' is defined as follows: 

l' = / [(P 2 > e2 )> ■ • ■ ! (Pm,e m )\ if ClearProf it(M, c) V TargetFailed(M, c) 
( l otherwise 



In addition, K = (3' if TargetFailed(M, c) and K = (3 otherwise. 
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(3) ( Transaction ) If the condition of (1) does not hold then for any r" = 
( u , r", . . . , r") > 0 such that U(s)(r") — U (s)(r) +Accumulated(7) > -mi, we 
have K = 7, tc = 0, s' = s, r’ = r" , and l' = Update(Z, U(s){i J ) — U(s)(r)). 

We denote by Evolutions(Af, c) the set of evolutions of M from c. 

A trace of M from c is a list of evolutions l with either l = [ ] or l = e : l', 
where e = {c,d ,v)k G Evolutions(M, c) and V is a trace of M from d. We 
denote by Traces(Af, c) the set of traces of M from c. □ 

Let us comment the previous definition. First, if one of the guards associated 
with a transition between states holds then the state changes. In addition, the 
time counter of the state is reset to 0 and the expiration dates of the pending 
accounts are shifted to fit the new counter. The second clause reflects the situ- 
ation where the machine let the time pass by. In this case, the amount of time 
has to be less than or equal to the maximal waiting time. Besides, if the elapsed 
time is the one in which a positive or negative previous profit expires, then either 
this profit is considered clear or a failure is produced, respectively, being such 
profit eliminated from the list. In the second case, we label the transition by /3' 
to denote an undesirable behavior of the agent associated to the corresponding 
USM. Finally, if a machine performs a transaction then we require that it does 
not give resources that it does not own and that the accumulated losses stay 
below the maximal threshold. When a transaction is executed then the pending 
accounts are updated to register the new transaction. Let us remark that the 
second and third types of transition can be performed only if the corresponding 
USM cannot change its state. 

In the next definition we identify the traces that are free of failures. 

Definition 6. Let M be a USM and c be a configuration of M. Let us sup- 
pose ci = c and let a = [{ci,c 2 ,ti) Kl , • • • , (c n _i, c n , € Traces(Af, c) 

be a trace of M from c. We say that a is a valid trace of M from c if there does 
not exist 1 < i < n — 1 such that K, = f3' . We define the set of valid traces of M 
from c by ValidTraces(AL, c). □ 



3 Composing Single Agents to Create Systems 

In the previous section we have defined the full set of valid transitions a USM can 
perform. Thus, the definition of the formal specification framework for a single 
agent is complete. At this point we have to extend the previous framework so that 
systems, made of USMs interacting among them, can be defined. This notion will 
allow us to represent e-commerce multi-agent environments. Intuitively, systems 
will be defined just as tuples of USMs, while the configuration of a system will 
be given by the tuple of configurations of each USM. 

Definition 7 . Let have AL, = (S*, s» n ,, V, Ui,ati, mii , Tf). We say that the tuple 
S = {Mi, . . . , M m ) is a system of USMs. For any 1 < i < m, let c, be the 
configuration of M». We say that c = (ci, . . . , c m ) is the configuration of S. □ 
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The transitions of a system will not be the simple addition of the transitions 
of each USM within the system, as some of the actions a USM can perform will 
require synchronization with those performed by other USMs. This will be the 
case of passing of time and transactions. In the former case, the system will be 
able to idle an amount of time t provided that all of the USMs can idle t units 
of time. This does not constrain the capacity of agents to idle for longer periods 
since a long period of time could be denoted by several time steps. Let us note 
that passing of time will affect equally to all the USMs in the system. In other 
words, if a certain amount of time passes for one machine then it must also pass 
for any other machine of the system. Regarding synchronization of transactions, 
we will suppose that they are conservative in the sense that the total amount of 
resources existing in a system remains invariant after a transaction is performed. 
The only actions that do not require a synchronization are the ones associated 
with changing the state of a USM. In contrast with transactions and passing of 
time, changing the state is not a voluntary action. In other words, if the condition 
for a USM to change its state holds then that USM must change its state. In the 
meanwhile, transactions and passing of time transitions will be forbidden. 

In the following definition we identify the set of evolutions a system can per- 
form from a given configuration. Once again, a transition may be a changing 
of state, a passing of time, or a transaction. In order to make explicit the fail- 
ure of any of the USMs in the system, we distinguish passing of time transitions 
producing a failure. In this case, we will explicitly indicate the set of USMs pro- 
ducing a failure. Hence, the label p A denotes a passing of time transition in 
which the USMs included in A produced a failure. So, a failures-free passing of 
time transition is denoted by /3g. 

Definition 8. Let S = be a system and c = (ci,...,c m ) be 

a configuration such that we have M* = (Si, Si n i,V,Ui,ati,mii,Tf) and c, = 
( Si,ri , If) for any 1 < * < to. An evolution of S from c is a tuple (c, d , tc)K where 
c' = (c'l, . . . , c'J, with c' = (4 rf If), K £ {a, 7} U {p A \ A C {1, . . . , to}}, and 
tc £ 1R + are defined according to the following options: 

(1) (Changing the state ) If there exists (ci,d(, 0) a € Evolutions(Mj, cf) then 
K = a, tc = 0, and for any 1 < j < in we have cl- = Cj if i 4 J> while 

4 = 4 '- 

(2) (Passing of time ) If the condition of (1) does not hold and there exits tr such 
that for any 1 < i < m there exists (c,, cf ,tr)s £ Evolutions (Mi,cf) with 

5 € {P, P'}, then tc = tr, c' = cf for any 1 < i < m, and K = p A where the 
set A is defined as A = {i \ (ci,df ,tr)p> £ Evolutions(Mj, c*)}. 

(3) ( Transaction ) If the condition of (1) does not hold and there exist two in- 
dexes j and k, with j ^ k, such that for l £ {j, k} we have (ci,cf, 0) 7 £ 
Evolutions(M;, cf) and cf = (sf, rf ,lf), with rf+rf = r" +rf, then K = 7, 
tc = 0, dj = dj, cf = c", and for any 1 < i < m, with i 7^ j, k, we have 
c'i = Ci. 

We denote by Evolutions^, c) the set of evolutions of S from c. 
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A trace of S from c is a list of evolutions l where either l = [ ] or l = e : l', 
being e = (c,c',v)k G Evolutions^, c) and l' a trace of S from d . We denote 
by Traces(S l , c) the set of traces of S from c. □ 

Let us comment the previous definition. If a USM can change its state then the 
corresponding transition is performed while any other USM remains unmodified. 
If no USM can modify its state then passing of time and transaction transitions 
are enabled. In the first case, the system can let the time pass provided that 
all the USMs belonging to the system can. In the second case we require that 
trading USMs can (individually) perform the exchange and that goods are not 
created/destroyed as a result of the exchange. Let us note that only bilateral 
transactions are considered since any multilateral exchange can be expressed by 
means of the concatenation of some bilateral transactions. 

Next we present a useful result in order to understand the behavior of trans- 
actions. We show that the utility of the agents that do not fail cannot decrease 
as long as they remain in the same state (that is, as long as they keep the same 
preferences), provided that the time has no influence on the utility in that state. 

Lemma 1 . Let S = (Mi, . . . , M m ) be a system where for any 1 < j < m we 
have Mj = (Sj,Sj i n ,Vj,Uj,atj,mij,Tj). Besides, let a be a trace of S such 
that a = [(ci,c 2 ,ti)j{- 1 ,...,(c n _i,c n ,t n _ 1 )ic w _ 1 ], where for any 1 < j < n we 

have Cj = ((sj, rj, l {), . . . , (s J m , r 3 m , /^)). Let us suppose that for some 1 < k < m 
we have = [ ] and let 1 < * < n be such that l k = [ ] and for any i < j < n it 
holds s J k = s\ and Kj {/3 a \ k £ A}. Let us also suppose that AUk d£)(x) _ q 
holds. Under these conditions we have U{sk){r k ) > U{sk){r l k ). 

Proof. The agent M k stays in the same state s‘ k from configuration d to con- 
figuration c n . Thus, its utility function does not change during this period. In 
addition, since there does not exist Kj, with i < j < n, such that Kj = /3a, 
with k £ A, the agent M k does not fail in the evolution from configuration c* to 
configuration c n . Let us suppose U(sk)(r k ) < U(sk){r l k ). Then, since the time 
does not affect the utility function of k because AUk ^A^ x '> = o, the reduction of 
utility must be produced by a transaction. So, the set Q C n} such that 

for any j £ Q it holds Kj = 7 and U(sk)(r 3 k ) < U(sk){r 3 k ~ 1 ) must be non-empty. 
Let us note that for each j £ Q the effect of such negative transaction will be 
immediately included in its list of pending accounts lj. . However, since l k = [ ], 
such a profit disappears from the list before the n th transition is performed. So, 
there are two possibilities: Either the negative profit expired (which is impossible, 
since M k did not fail) or it was compensated before achieving c n . Nevertheless, 
if it was compensated then it cannot influence negatively the final utility of M k . 
Thus, we conclude that U(sk){r k ) < U(sk)(r l k ) is not possible. 

□ 

Similarly to the reasoning that we did for single agents, we can identify the 
valid traces of systems. In this case, we are interested in identifying the traces 
such that a specific USM belonging to the system produces no failure. 




Specification of Autonomous Agents in E-commerce Systems 



41 



Definition 9. Let S = (M\, . . . ,M m ) be a system and c be a configuration 
of S. Let us suppose ci = c and let er = [(ci, C 2 , ■ ■ ■ , (c n -i, c n , £ 

Traces(S', c) be a trace of S from c. We say that er is a valid trace of S from c for 
the USM Mi if there does not exist 1 < j < n — 1 such that Kj = (3a with i € A. 
We denote the set of valid traces of S from c for Mi by ValidTraces(5', c, Mi). 

□ 



4 Case Study: Kasbah 

In this section we apply our formalism to specify the system Kasbah [3] . Kasbah 
is one of the pioneer proposals in the field of e-commerce multi-agent systems. 
It consists of a market of autonomous commerce agents that behave on behalf 
of their corresponding users. The agents interact with each other in order to 
reach good deals. Basically, agents are either sellers or buyers. Each agent is 
intended to buy or sell one single specific item at the best possible price (lowest 
or highest respectively). Every time a user wishes to perform a selling/buying 
operation, he creates a new Kasbah agent. Let us suppose that he wants to buy 
an item (the case of selling is symmetric) . The user chooses the item he wants to 
buy and configures the agent according to four requirements: The initial price it 
should offer to an agent selling that item (ip), the maximal price it should pay 
in exchange of the item ( mp ), the deadline when it should refuse to buy the item 
( d ) , and a function denoting the way the agent should increase the buying price 
as time passes. This last function can be linear, square, or cubic. It will work 
so that the price mp will be offered exactly when d comes. The function will be 
defined by its exponent ex. So, if it denotes the kind of item the buying agent is 
interested in, mo denotes the money, and t denotes the time elapsed, then the 
utility function of the buying agent is defined as 

u(t, it, mo) = mo + (ip + a ■ t) ex ■ it 

1 

where a = mp ~ lp . The value a can be easily obtained by taking into account 
that the maximal price mp should be paid just when the deadline d expires. 

Using a similar reasoning, the utility function for a seller agent is defined as 

u(t, it, mo) = mo + (ip — a ■ t) ex ■ it 

1 

where a = . Both buyer and seller agents will be specified by using 

a USM with two states. The first one, si, will denote that the agent is active, that 
is, it can make transactions with other agents. The second one, S 2 , represents 
that the agent is inactive. As long as the agent stays in si, it can make a deal 
with another agent provided that the transaction is good according to its utility 
function. If the time runs out and the deadline comes before any transaction is 
performed then the agent state changes to S 2 . In S 2 no transaction is accepted 
by the agent. This will be expressed, in the case of the buyer, by using a utility 
function that gives a full importance to money, so transactions will be no longer 
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u(t, it, mo)=mo+(ip+a ■ t) ex ■ it 



(si, Q i, Z\, S2) 




u(t, it, mo) 



mo 



u(t, it, mo)=mo-\-(ip—a ■ t) ex ■ it 



(si, Q[, Z[, S2) 




s ' 2 ) u(t, it, mo) = mo 



Fig. 2 . USMs of the buyer and seller agents 



possible. Besides, in the case that a transaction is performed before the deadline, 
the agent will immediately move to the state S2. The corresponding transition 
will indicate that the item is deleted from the basket of resources of the agent, 
denoting that the agent sends the bought item to its user. 

Definition 10. The USM Mb associated to a buyer agent is defined as the tuple 
(S, Si n ,V,U, at,mi,T), where S = {si,S2}, Si n = si, V = ( t,it,mo ), at and mi 
are set to any arbitrary values, U is defined as 

1 

U(si)(t, it, mo) = mo + (ip + a - t) ex ■ it where a = — ~ lp 

U{s2)(t,it,mo) = mo 

and the set of transitions T is defined as T = {(si, Q 1, Z\, S2), (si, Q 2, Z 2 , S2)}, 
where Q\(t,it,mo) holds iff t > d, Zi{it,mo) = (it, mo), Q2(t,it,mo) holds iff 
it = 1 , and Z2(it, mo) = (it — 1 , mo). □ 

The definition of the USM M s associated with sellers is quite similar. The 
only differences are the utility function in the first state s^, which is defined 
as we said before, and the functions denoting the modification of resources in 
transitions. In this case, the roles of Z\ and Z2 must be swaped, as the item will 
be returned to the user in the case that it could not be sold. In Figure 2 we show 
graphical representations of the USMs corresponding to buyers and sellers. Once 
both buyer and seller agents are defined, a minimal system S can be trivially 
defined by composing both agents so that S = (Mb, M s ). More complex systems 
can be defined containing several buyers and sellers that trade with different 
items. 
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5 Conclusions and Future Work 

In this paper we have presented a framework to formally specify e-commerce 
systems where agents represent the interest of the users. We concentrated on 
the high level part of the behavior of agents. We have used a notion, called 
utility state machines, that allows us to specify the economic behavior of agents. 
Finally, we have applied our framework to the specification of the main entities 
appearing in Kasbah. 

We contemplate two lines for future work. In the first one, with a major theo- 
retical component, we plan to extend our notion of USM so that low level behavior 
is also taken into account. In the second one, with a more practical component, 
we would like to apply our framework to other agent-based e-commerce systems 
(as we have done with Kasbah). 
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Abstract. Internet and mobile technology enable businesses to invent new 
business models by applying new fonns of organization or offering new 
products and services. In order to assess these new business models there has to 
be a methodology that allows identifying advantages that are caused by 
electronic and mobile commerce. The proposed approach builds upon the 
theory of informational added values that provides a classification of gains 
produced by information work. This theory is extended by the definition of 
categories of technology inherent added values that result in informational 
added values. These informational added values can be perceived by users of 
information products and services and therefore be used to assess electronic 
offers. The relationship between technology inherent and informational added 
values will be clarified with examples of real business models. Furthermore, a 
classification of basic business model types will be provided. 



1 Introduction 

Applications that build upon Internet technology like E-mail and the World Wide 
Web made possible a completely new use of digitally available information. Starting 
from a simple text-based information exchange, the Internet has become a world-wide 
information system and application platform. In the end of the 1990's the Internet 
hype facilitated the foundation of many new companies that formed the so called New 
Economy. Even after the industry cooled down and many of the Dotcoms 
disappeared, companies are still in the position to make money on the Internet and 
Digital Transformation of organizations is going on. There has to be something 
inherent to this technology that causes positive effects on businesses and also on 
every day's life. 

An analysis of the Internet's characteristics shows important properties that can help 
to explain this phenomenon: Global interconnectedness and instantaneous transport of 
information based on standardized protocols combined with a previously not possible 
presentation potential allowed to offer products and services based on new business 
models. In the recent years mobile communication techniques introduced new 
technical properties and expanded already present ones. They have become a basis for 
new business models. But again, the same happened with these business models as 
with the Internet-based ones: Many of them were presented and most of them already 
disappeared, e.g. in the field of mobile payment [6]. In order to assess existing and 
future business models based on modern information and communication 
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technologies there is a need for an evaluation methodology. Technological 
capabilities have to be identified as well as benefits that users and producers of 
electronic offers can achieve when using them. 

The rest of this paper is organized as follows. Section 2 discusses related work in 
the field of assessment of business models and introduces the theory of informational 
added values. This theory allows describing advantages caused by information 
systems or goods and services that were produced with their help. These advantages 
are called informational added values and can be categorized depending on different 
aspects of utility. In section 3 Internet and mobile technology are analyzed in order to 
define characteristics of information and communication systems that are built upon 
them. These will be termed electronic added values and mobile added values. In 
section 4 it is explained how electronic and mobile added values can cause 
informational added values and how this can be used for an assessment of electronic 
offers. Furthermore, basic types of business models will be described and categorized 
that represent the building blocks for more complex ones. In section 5 an exemplary 
business model will be assessed with the help of the proposed methodology. Section 6 
gives a summary and outlook. 

2 Informational Added Values 

Every business model has to prove that it is able to generate a benefit for the 
customers that will pay for it. This is especially true for businesses that offer their 
products or services on the Internet. Since the beginning of Internet business in the 
mid 1990s models have been developed that tried to explain advantages that arose 
from electronic offers. An extensive overview of approaches can be found in [11]. At 
first, models were rather a collection of at that time few business models that had 
already proven to be able to generate a revenue stream [3, 15, 18]. Later approaches 
extended these collections to a comprehensive taxonomy of business models 
observable on the web [13, 17]. Only [18] provided a first classification of eleven 
business models along two dimensions: innovation and functional integration. Due to 
many different aspects that have to be considered when comparing business models 
authors introduced taxonomies with different views on Internet business. This 
provides an overall picture of a firm doing Internet business [10], where the views are 
discussed separately [1, 2, 5, 14, 22]. Views are for example commerce strategy, 
organizational structure or business process. The two most important views that can 
be found in every approach are value proposition and revenue. A comparison of 
proposed views in different approaches can be found in [16]. While the view revenue 
describes the rather short-term monetary aspect of a business model the value 
proposition characterizes the type of business that is the basis of any revenue stream. 
To describe this value proposition authors decomposed business models into their 
atomic elements [9]. These elements represent offered services or products. Models 
that follow this approach are for example [1] and [22]. Another approach that already 
focuses on generated value can be found in [9]. There, four so called value streams 
are identified: virtual communities, reduction of transaction costs, gainful exploitation 
of information asymmetry, and a value added marketing process. Some approaches 
define an enterprise ontology to be able to describe actors and value exchanges in a 
given business model scenario [4, 17, 21]. However, no systematics is provided that 
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links types of offered products and services to generated values for participating 
actors. 

Since companies use Internet technology to improve their value production, it has 
to be determined what kinds of benefit can theoretically be realized for customers, 
vendors or even involved third parties. The theory of informational added values [8] 
provides an analysis of the impacts of information work in information markets. 
Utility that can be perceived by users of goods that result from information work is 
represented as a set of informational added values (IAV). As there are different 
aspects of utility, informational added values can be classified into eight main 
categories. There are efficiency, effectiveness, aesthetic-emotional, flexible, 
innovative, organizational, strategic, and macroeconomic added values. 

• Efficiency added values can be realized when the speed or the cost-effectiveness 
of an operation increases. For example, customers of online services like online 
banking or brokerage can initiate transactions at home instead of going to a certain 
location during business hours and therefore save time. Not only is this beneficial 
for customers but also for service providers because the task of collecting data and 
filling out forms is already performed by the customer. In this way a better cost- 
effectiveness can be achieved. 

• Effectiveness added values cover an augmentation in output quality. This can be 
either a better achievement of a given goal or that something is made possible that 
previously did not work. An example would be a search engine that is able to find 
the location of books in a library based on the title. If books were also available as 
electronic editions, then this would allow downloading the document. This would 
further increase the achievement of the given goal, namely to find and read a 
book. 

• Aesthetic-emotional added values address subjective factors such as well-being, 
job-satisfaction or acceptance of performance. This added value can be found for 
example in above mentioned online brokerage example. The user can access stock 
exchange information through an online-portal where multiple charts with 
information about the current trading situation are presented. The customer is now 
able to see a lot of information at once, without having to search for it. 

• Flexible added values allow a higher level of flexibility in the production of goods 
and services that consist of information. This can for example be found in the 
production of personalized music CDs where tracks can be arranged according to 
the individual wish of a customer. Therefore the variability of goods increases, i.e. 
there is a greater range of offered products. This variability can also be achieved 
for classical goods and services with the help of modern information and 
communication techniques, e.g. with production planning systems. It is suitable to 
extend the definition of flexible added values to the production of classical goods. 

• Innovative added values cover the creation of entirely new products or services (or 
a combination of both) through the usage of new means of communication. Online 
services that provide driving directions would not be possible without the use of 
the Internet. Another example is the customer-individual production of bulk 
articles through mass customization strategies. The innovative aspect here is that 
these personalized articles are sold with only a slightly higher price. But from an 
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organization's perspective, innovative added values will disappear, when other 
companies offer the same product or service. 

• Organizational added values cover the opportunity to build new forms of 
organization through the use of information and communication systems. This can 
affect companies' organization structures as well as the reorganization of their 
business processes. Focus here is on administrative and dispositional activities. 
Examples for the creation of organizational added values through information and 
communication technology are virtual companies as temporary, mission-bound 
networks or mobile access to enterprise resource planning systems. 

• Strategic added values qualify advantages that go beyond the operational and 
tactical level by influencing a company's position in a market segment. If a 
significant competitive edge can be achieved or disadvantages regarding the 
market share can be avoided strategic added values are present. A strategic 
advantage is always based on one or more other added values, e.g. on the 
opportunity of worldwide customer acquisition for a small specialized company 
that has an added value with effectiveness impact on customer reach. 

• Macroeconomic added values describe advantages that go beyond the level of 
single companies and result in impacts on economy or society as a whole. These 
added values also emerge from one or more of the other added values and denote 
improvements in the achievement potential of a society. For instance the effect of 
office automation to the occupational image of a secretary. Nowadays, the role of 
a secretary is more an executive assistant than a copy typist. 

The different aspects of utility that are provided by these eight categories have also 
different user perspectives. Macroeconomic added values aim at improvements of a 
whole society. Strategic, organizational, innovative, and flexible added values can 
only be realized in organizations that offer goods or services. Efficiency, 
effectiveness, and aesthetic-emotional added values can even be realized by a single 
person. This can be a private user or employees of the above mentioned organizations. 
But organization-centric added values can also affect private users because 
improvements within companies can be handed on to customers for example by 
reducing prices or offering new or more products. It can also be noticed that often 
informational added values cannot be seen separately from each other. For example, 
there are interrelations between effectiveness and efficiency added values. In the 
library example, the goal achievement can be measured in increased speed of search 
and is therefore more efficient. Another example is increased customer satisfaction 
for a parcel service through enhanced skills in shipment tracking. An online tracking 
system produces aesthetic-emotional and effectiveness added values that can as well 
be accompanied with an efficiency added value, if this solution decreases the number 
of call center operators at the same time. Since strategic and macroeconomic added 
values can not appear individually, their existence can only be explained with the 
dependence on other added values. Therefore it can be stated that the determination of 
informational added values in electronic offers always depends on the particular point 
of view and the aspect one wants to examine. Also, it is not excluded that one added 
value causes another, e.g. organizational improvements can lead to cost savings or to 
higher job-satisfaction. 
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3 Electronic and Mobile Added Values 

3.1 Concept 

Informational added values as described in section 2 are impacts of information work 
that is performed in order to produce or use goods and services. This is based on 
technologies that provide new possibilities of handling and transport of information. 
Modern information and communication systems have advantageous properties that 
represent technology-specific added values. Such system technology-specific added 
values are not informational added values but they can cause them. IAV result from 
the use of information systems (or from goods and services that have been produced 
with their help) if users accept to pay for their anticipated benefit or if they appreciate 
them in another than monetary way [8]. To understand and discern conditions and 
results, technology-specific added values have to be identified. Technologies relevant 
to this question are the Internet and mobile communication techniques. Mobile 
communication builds upon techniques that are already used in Internetworking and 
adds some more properties to it. Therefore these two technologies will be analyzed 
separately to show, which characteristics dominate and which technology-specific 
added values exist in each case. 

3.2 Electronic Added Values 

In order to define general added values of Internet technology, its properties have to 
be analyzed. Networked computers are able to exchange digital data without any 
reasonable delay, i.e. instantaneous transport of information is possible. Standardized 
communication protocols like the TCP and IP as well as emerging standards for data 
exchange and media representation allow interconnection of computers based on 
different operating systems and application systems. These standards have led to a 
global interconnectedness of networks and computers. Every computer that is 
connected to the Internet is able to exchange data with every other in this global 
network even if they are separated by thousands of miles. Due to its non-proprietary 
character there are no access restrictions to the Internet. Another property is the 
enhanced presentation potential that was added to the Internet. Today, browsers are 
able to present not only text annotated with HTML-tags but also images, audio and 
even real-time video streams. Based on these properties four added values can be 
defined for Internet-based technology. These are called electronic added values 
(EAV): 

• Reduction of temporal and certain spatial limitations 

This added value is based on the properties instantaneous transport and 
interconnectedness. Online offers can therefore be accessed at any time and from 
almost everywhere without any noticeable time delay. Only a computer connected 
to the Internet is needed. Data exchange is not reduced to textual information so 
that digital products and services, e.g. music can also be transmitted. Even a 
combination with classical goods is possible where a product is ordered online and 
delivered by a logistics provider. This EAV mainly causes efficiency and 
organizational added values. It can be used for many business models because 
time and location independent access can be realized without much additional 
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effort. But to offer a 24/7 service a suitable server infrastructure has to be 
maintained. 

• Reduction of technical limitations 

This EAV can be explained with the existence of communication and presentation 
standards. This facilitates the elimination of heterogeneity problems. A wide range 
of applications, especially business applications, benefit from this added value. 
Data and process integration can be achieved and inconsistencies caused by 
handoffs will be reduced. This added value leads in particular to organizational, 
efficiency and effectiveness added values. 

• Unrestricted access 

The concept of the Internet is based on free access through standardized protocols. 
Everybody is able to connect to the network without having to buy expensive 
technology, and the number of participants is not restricted. For example, a Web 
site of a small company has the same preconditions as the one of a global player. 
Everyone can offer and use information or services on the Internet so that 
transparency of the market increases. To benefit from this transparency search 
engines and directories are needed in order to find certain offers. This EAV 
mainly causes strategic added values that are based on efficiency, effectiveness, 
and aesthetic-emotional added values. 

• Multi-mediality and interaction 

Multi-mediality describes the enhanced presentation potential of the Internet that 
can be used to stimulate users. This is extended with interaction capabilities that 
make use of the instantaneous transport of data. Thus, direct and personalized 
interaction is possible, e.g. for product configuration. This EAV often leads to 
effectiveness and aesthetic-emotional added values and can also cause innovative 
added values. 

3.3 Mobile Added Values 

Mobile communication techniques extend Internet technologies and add some more 
characteristics that can be considered as additional benefits. Therefore an own class of 
technology-specific added values is defined and named mobile added values (MAY). 
These added values based on mobility of portable devices are: 

• Ubiquity 

This MAV describes the possibility to send and receive data anytime and 
anywhere. It is originated in the typical usage of mobile devices which accompany 
their user nearly anytime and anywhere. It permits the reception of time-critical 
and private information. Additionally, persistent attendance leads to an increased 
reachability. For example it allows getting warnings about stock exchange loss 
even if the recipient is not reachable by other forms of communication. This MAV 
can cause all of the mentioned IAV, especially efficiency, effectiveness, and 
aesthetic-emotional added values. 

• Context-sensitivity 

Mobile devices can be used for delivery of customized products or services fitting 
the particular needs of the user in his current situation. This can be achieved in 
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several ways. The current location of the user can be determined and, if necessary, 
correlations with the location of other users can be analyzed. Sensors that are built 
into mobile devices can send information about an user's vital functions over the 
mobile network. Two other possibilities are already known from electronic 
business. Personalized preference profiles and direct interaction can also be 
applied in a mobile scenario where they get a higher importance. Typical 
applications based on the MAV of context-sensitivity are location based services. 
Context-sensitivity also leads to all IAV, and in particular, innovative added 
values are possible. 

• Identifying functions 

The possibility to authenticate the owner of any mobile device through his 
subscriber identification is immanent to a cellular phone network. The typical 1:1- 
attribution of a mobile device to its user (which is perhaps not true for any other 
technical device except a wristwatch) and the possibility to use further means of 
authentication on the device result in identifying functions of mobile devices. This 
MAV can be used for applications with security restrictions like mobile payment 
or for applications that utilize user profiles based on the behavior of the customer, 
enabling 1:1 marketing concepts. Mainly, effectiveness added values can be 
realized with identifying functions. 

• Command and control functions 

Mobile devices can be used as remote control for other devices using personal, 
local, or wide area networks. Mobile technology extends previous Internet-based 
solutions, where remote control was only possible for stationary devices. Now, the 
combination with ubiquity allows that the target device may be mobile, too. This 
could be the mobile phone of other users or a device with ubiquitous computing 
technology so that rule based automation and device-to-device (D2D)- 
communication is possible. Command and control functions primarily cause 
effectiveness added values. 

4 Assessment of Electronic Offers 

4.1 Methodology of the Added Value Concept 

After having presented informational as well as electronic and mobile added values, it 
is possible to analyze dependencies between them. Benefits of an electronic offer are 
assessed by comparing it with a non-electronic offer [12]. Since it is not sufficient to 
simply make a conventional (non-electronic) offer available through a web site or 
mobile device, e.g. digital photographs of a newspaper, informational added values 
are necessary to give users a reason for accessing it. In order to determine how and 
which informational added values can be derived from electronic and mobile offers, a 
methodology will be introduced next. 

When comparing an offline solution to an according electronic offer, e.g. a 
newspaper with its online edition, then informational added values have to be created 
for at least one participating group of actors, in this case users or publisher. These 
IAV can only be derived from electronic added values that were used to create this 
offer. Figure 1 shows the systematics of application. 




An Approach for Assessment of Electronic Offers 5 1 



If EAV are applicable, this results in 1AV that have not been existent in the offline 
solution. If a mobile offer is examined, then MAV have to be identified that are 
applicable to this solution. These MAV result in additional 1AV compared with the 
electronic offer. In our example, the online edition of a newspaper results, among 
other, in efficiency added values, because news can be presented immediately instead 
of the next day. A mobile solution, where news can be pushed on the device, results in 
additional efficiency added values, because it allows reaching the user faster. 
Considerations like that have to be done for every EAV-IAV-combination in an 
electronic offer and for mobile offers respectively. 

The diagram shown in figure 2 allows a structured analysis of the dependencies 
between EAV and IAV. EAV can be found in the rows of the matrix and LAV in the 
columns. For a particular business model it is analyzed if an EAV is applicable at all. 
If yes, then for all possible IAV an estimation of influence is given. In this model 
strong influence, influence, or no influence is possible. The estimation is dependent on 
the person who analyzes. A customer would probably have another estimation as the 
service offerer. Ideally, an independent person should assess the business model and 
consider all points of view. 
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Fig. 1 . Derivation of informational added values 

There is only an ordinal scale provided, what can cause inconsistent assessments 
when more than one person separately analyze one offer. However, the possibility 
that dependencies between certain EAV and IAV are equally assessed is high, if for 
every IAV all necessary criteria are defined, e.g. efficiency added values describe the 
improvement of two criteria, namely time and cost. 

4.2 Typology of Business Models 

The evaluation of real business models showed that some few business model types 
recur. These basic business model types have been used for building up more 
complex business models. They can be classified according to the type of offered 
product or service. A categorization based on this criteria is highly extensible and thus 
very generic [19]. Unlike other classifications of electronic offers (see section 4.1) 
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this approach can also be applied to mobile business models that e.g. use location 
based services to provide a user context. Even future business models can be 
integrated that are not yet known. 
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Fig. 2. Diagram for a structured analysis of dependencies 

Figure 3 shows the categorization of business model types based on offered 
service. First, it has to be distinguished whether goods and services can be produced 
and exchanged exclusively in a digital way. If there is a part of production that cannot 
be done only by data exchange, i.e. there is a physical product involved. Not digital 
goods and services can be tangible or intangible. While physical products themselves 
are tangible services that only need physical objects to be performed are intangible. 
Hence two basic types can be derived: classical goods and classical service. Digital 
goods and services can be divided into action and information. 

The category information represents the offering of data, e.g. multi-media content 
for entertainment purposes or daily news. Basic types are context and content. An 
offer has the basic type context if it describes, uses, or provides information about 
someone's situation, e.g. position, environment or needs. This can be achieved either 
by user profiling or more effectively by suitable mobile technology. The category 
content describes offers that provide news and information about politics, economics, 
entertainment, arts and so on. Online and mobile games are also included. Activities 
that process, manipulate, transform, select, or systematize data are contained in the 
category action. This category consists of three basic types: Service, intermediation, 
and integration. Service contains offers where activities using digitally encoded data 
are provided e.g. an online translation service. Activities that classify, search, select or 
mediate belong to the basic type intermediation, e.g. search engines. Finally, the 
category integration comprises offers that combine several other offers to one, 
probably with the use of personalization. This can even lead to user individual offers 
where the user does not even know about the combination of different offers. For 
example, an offer could be an insurance bundle specifically adjusted to a customer's 
needs. The individual products may come from different insurance companies. 
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Fig. 3. Categorization of basic business model types 



The goal of the proposed approach is to be able to assess business models and also 
non-commercial offers that are based on modern information and communication 
techniques. Therefore, an empirical analysis of real business models has to show, 
whether informational added values and the methodology to identify them is suitable. 
In a study, the methodology was successfully applied to 153 real business models of 
electronic and mobile commerce. In order to show how the approach was used, one 
example of an assessment will be presented next. 



5 Example: The Business Model of TVinfo 

TVinfo [20] provides television program information on the Internet. There is no 
printed edition. Unregistered users can browse the program and read news related to 
entertainment. Registration is free of charge and allows using more services. 
Registered users can customize their view, i.e. they can choose what channels will be 
displayed and also how information is presented. There is a service that allows putting 
a television program overview on private homepages. A personal agent can be used to 
find certain television programs based on title, director and actors. The agent searches 
the future television program based on these criteria. There is also the possibility to 
buy a program subscription which allows selecting movies online, and automatically 
program a digital video recorder based on special software provided by partner 
companies. This software can be ordered online as well as the subscription itself. 
Programs can be added to a reminder. Entries can be viewed online or sent to a 
mobile phone by a SMS-service. A second mobile offer is the possibility to download 
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the customized television program to a PDA using the AvantGo software [7]. These 
two mobile offers will not be considered below. 



(Classical) goods 



• Video recording software that is shipped on CD 



(Classical) service 
Service 



• Data preparation service for video recording software 

• Television program service for own homepages 



Intermediation 



• Personal agent that searches programs based on preferences 



Integration 



• Combination of television program service and video recording software 

• Integration of news to the TVinfo Web site 



Content 



• TV and entertainment news 



Context 



• Personalized presentation of the television program based on user profiles 
Fig. 4. Classification of the TVinfo's business model 

Four participating groups of actors can be identified: Viewers, TV channels, TVinfo, 
and software vendors. For these groups all 1AV have to be determined. Before this is 
done the business model of TVinfo will be classified according to the proposed 
categorization. For this purpose, a list is compiled where all seven basic business 
model types appear. For each basic business model type occurrences are documented. 
Fig. 4. shows the classification of TVinfo's business model. For each identified basic 
business model type the dependencies between EAV and IAV can now be analyzed. 
One can thereby revert to general relations between specific EAV and IAV that are 
reflected in specific business model types. For example, the business model type 
integration uses two EAV, namely reduction of technical limitations and multi- 
mediality and interaction. These result mainly in effectiveness added values so that 
this IAV is likely to appear when using this basic business model type. In the 
following these considerations have been made and aggregated so that for each EAV 
the resulting IAV can be listed. 

Reduction of temporal and certain spatial limitations has a strong influence on 
efficiency. Users save time because there is no need to buy a television program 
magazine at a store. Cost can also be saved but only if the user has not to be online 
very long in order to get the desired information. Greater effectiveness can be 
perceived by the online publisher, software vendors, and the TV channels. Combined 
with the unrestricted access much more potential viewers can be informed about the 
television program. Reduction of technical limitations allows users to automate video 
recording by using TVinfo's program data with the recording software. This results 
primarily in increased effectiveness and also leads to efficiency and aesthetic- 
emotional added values, because the user can save the time of manually programming 
the video recorder. The software vendors that cooperate with TVinfo will be able to 
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sell more of their recording software due to this effective advertising. From TVinfo's 
perspective more variants of its product can be offered and thus flexibility added 
values can be realized. Since such an automation of video recording has not been 
possible before this also causes innovative added values. Unrestricted access results 
in IAV for TV channels and viewers. TVinfo offers program information without 
having to register or pay. TV channels can reach more potential viewers with their 
television program and therefore realize effectiveness added values. Unregistered 
users of TVinfo are able to access full information what increases their contentedness. 
Multi-mediality and interaction allows personalization of the television program based 
on user input. Users are able to find information more quickly if their view is 
customized to their needs. This is more effective and also more efficient. Besides that 
personalization results in higher variability of the television program service and thus 
in flexible added values. Innovative added values are caused by the search agent that 
interacts with the user. As soon as an appropriate program is found it puts the 
information to a list so that the user is able to read it. 

Since TVinfo has no printed edition the identified IAV have to form a strategic 
added value so that it can still exist on the market. Reachability is given by reduction 
of temporal and certain spatial limitation in combination with unrestricted access. The 
offer is highly customizable through the reduction of technical limitation and multi- 
mediality and interaction. Resulting from that the offer is primarily more effective 
compared to the offline solution. From the user's perspective also efficiency and 
aesthetic-emotional added values play an important role. TVinfo has increased 
flexibility in the production of its service and can also offer an innovative product in 
cooperation with its software partners. Figure 5 shows the matrix after assessment of 
the business model: 
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Fig. 5. Assessment of TVinfo's business model 
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6 Conclusion and Future Work 

This paper presents an approach to assess electronic and mobile offers. The theory of 
informational added values was extended by the definition of technology-specific 
properties that are advantageous when using them to build up business models or 
other solutions based on information and communication techniques. These so called 
electronic and mobile added values are the cause of informational added values. In 
order to identify particular dependencies between EAV/MAV and IAV in real 
business models a methodology was proposed. First, a business model is categorized 
into basic business model types, and then each basic offer is evaluated in respect of 
the existence of EAV and resulting IAV. Thus, with the help of this methodology one 
can clearly describe cause and result of an electronic offer. In order to build a 
comprehensive framework for comparison of business models, resulting IAV have to 
be quantified based on some criteria e.g. cost savings, extent of data redundancy, 
number of variants or willingness to pay. Up to now, only an estimation of influence 
is given. 
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Abstract. Combinatorial exchanges are double sided marketplaces with 
multiple sellers and multiple buyers trading with the help of combinato- 
rial bids. The allocation and other associated problems in such exchanges 
are known to be among the hardest to solve among all economic mech- 
anisms. In this paper, we study combinatorial exchanges where (1) the 
demand can be aggregated, for example, a procurement exchange or (2) 
the supply can be aggregated, for example, an exchange selling excess 
inventory. We show that the allocation problem in such exchanges can 
be solved efficiently through decomposition when buyers and sellers are 
single minded. The proposed approach decomposes the problem into two 
stages: a forward or a reverse combinatorial auction (stage 1) and an 
assignment problem (stage 2). The assignment problem in Stage 2 can 
be solved optimally in polynomial time and thus these exchanges have 
computational complexity equivalent to that of one sided combinatorial 
auctions. Through extensive numerical experiments, we show that our 
approach produces high quality solutions and is computationally effi- 
cient. 



1 Introduction 

1.1 Combinatorial Exchanges 

Combinatorial exchanges are two sided combinatorial mechanisms involving mul- 
tiple buyers and multiple sellers. Combinatorial exchanges (CEs) have major 
economic advantages due to the power of combinatorial bidding and highly ex- 
pressive bidding languages. However, they are, at the same time notoriously 
complex from a computational angle. There are two main computational prob- 
lems associated with CEs: 

— Allocation problem (also called winner determination problem or trade de- 
termination problem) : Choosing an optimal subset of bids so as to optimize 
a chosen performance metric (such as revenue maximization, cost minimiza- 
tion, surplus maximization, etc.). 
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— Pricing problem: Determining the actual payments to be made by the buyers 
and actual payments to be made to the sellers, so as to induce truthful 
bidding by the buyers and sellers. 

The above problems have been shown to be NP-hard [1, 2]. Researchers have 
therefore been seeking computationally efficient ways of solving these problems 
exactly or approximately. 

Numerous industrial applications have been reported in the literature for 
combinatorial exchanges. These include: collaborative planning [3], logistics and 
transportation exchanges [4, 5, 6], bandwidth exchanges [7], steel exchanges 
(for example, www.esteel.com), supply chain formation [8], e-procurement ex- 
changes [9, 10], stock exchanges, and exchanges for sale of excess inventory. 

1.2 Combinatorial Exchanges with Aggregation 

Our motivation in this paper is to study combinatorial exchanges where: 

— the demand can be aggregated, for example, a procurement exchange where 
the buyers’ demands can be aggregated, 

— the supply can be aggregated, for example, an exchange selling excess inven- 
tory where the sellers’ bids can be aggregated. 



1.3 Contributions and Outline 

We show that when agents are single minded the aggregated combinatorial ex- 
changes can be decomposed into two separate stages. 

— Stage 1: A combinatorial auction 

— Stage 2: An assignment problem 

Since the problem in Stage 2 can be solved exactly in polynomial time, therefore 
these exchanges have computational complexity equivalent to one sided combi- 
natorial auctions. We show that the iterative Dutch auction schemes proposed 
in [11] can be extended to solve the problem in stage 1 in a computationally 
efficient way to obtain near optimal allocations. 

The rest of the paper is organized as follows. Section 2 presents a review of 
relevant work to put our contributions in perspective. In Section 3, we present 
a mathematical formulation of the allocation problem for both demand aggre- 
gation and supply aggregation combinatorial exchanges and show that these 
exchanges can be decomposed into a two stage problem. In Section 4, we present 
generalized combinatorial Dutch auction mechanisms for solving the combinato- 
rial auction problem in stage 1. In Section 5, we present numerical experiments. 
We summarize the contributions of the paper in Section 6. 
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2 Review of Relevant Work 

Combinatorial exchanges (CE) are generalizations of combinatorial auctions. 
Also, CEs are multi-item exchanges, so they are more general than single item, 
multi-unit exchanges. Several survey papers have appeared on combinatorial 
auctions. These include the papers by de Vries and Vohra [2], and Narahari 
and Pankaj [12]. Similarly, there are several papers on single item, multi-unit 
exchanges, which are summarized in [1], 

The paper by Smith, Sandholm, and Simmons [ L3] presents a design for 
a market maker to construct and clear a combinatorial exchange for trading 
single units of multiple items. Pankaj and Narahari [14] have applied a decom- 
position idea to solve electronic exchanges trading multiple units of a single 
homogeneous item. The paper by Kothari, Sandholm, and Suri [15] considers 
a multi-unit, multi-item combinatorial exchange where acceptance of partial 
bids is allowed. Parkes, Kalagnanam, and Eso [16, 17] design a combinatorial 
exchange that is approximately efficient and approximately truthful. 

Iterative or indirect mechanisms are those where multiple rounds of bidding 
and allocation are conducted and the problem is solved in an iterative and incre- 
mental way [1]. Such an approach has several advantages: incremental informa- 
tion revelation, reduction in the complexity of the allocation problem, and prac- 
tical appeal in industrial applications. There are several iterative mechanisms 
proposed for combinatorial auctions [1, 16]. The use of iterative mechanisms for 
clearing combinatorial exchanges has been proposed by Biswas [18]. The mech- 
anisms proposed include auction mechanisms, Dutch auction mechanisms, and 
tatonnement mechanisms. 

Biswas and Narahari [11] have proposed the use of combinatorial Dutch 
auctions as an iterative mechanism for combinatorial auctions. They use the 
weighted set packing structure of forward combinatorial auctions to suggest an 
iterative forward Dutch auction algorithm for forward combinatorial auction 
problems, using generalized Vickrey auctions (GVA) with reserve prices in each 
iteration. They prove the convergence of the proposed algorithm and derive worst 
case bounds for the algorithm. Similarly, they use the set covering structure of 
reverse combinatorial auctions to suggest an iterative reverse Dutch auction al- 
gorithm for reverse combinatorial auction problems. They also show that the 
proposed algorithms produces near optimal quality solutions and are compu- 
tationally efficient. In this current paper, we will be using these combinatorial 
Dutch auction algorithms in the first stage of solving aggregated combinatorial 
exchanges. 

3 Formulation of the Exchange Problems 

We consider two special cases of combinatorial exchanges: Demand aggregation 
combinatorial exchanges and supply aggregation combinatorial exchanges. We 
assume that the goods can be freely disposed, that is, the supply is greater than 
or equal to the demand. 
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Table 1 . Notation used for the demand and supply aggregation exchange models 



M = {1, 2, m} Set of seller agents 



3.1 Demand Aggregation Combinatorial Exchanges 

Buyers submit their requirements, that is, the set of items and the quantities 
they want to procure. We assume that 

— the buyers are single minded i.e. they are interested only in a single subset. 

— the buyers submit atomic (all-or-nothing) bids i.e. they are interested only 
in a single set The buyers also submit their maximum willingness to pay for 
the set. 

The exchange pools the demand and accepts bids from the interested sellers for 
the aggregated demand. The allocation problem can be formulated as follows. 
We give the notation used in Table 1. 

The integer programming formulation of the exchange problem is: 



y(S, i) < 1 V* G M 

SCG 

Y a{S,k)y(S,j) < YJ2 a(S, k)y{S , *) Vfc VS C G 

SBk j£M S3ki£M 

y(S,i) = 0,1 VSCG.VieM 
y(S,j) = 0,1 vsc G,Vj e N 



Since the demand is aggregated we can decompose the above problem into two 
stages. In Stage 1, knowing the aggregated demands, we solve a combinatorial 
procurement problem to procure the demanded items at minimum cost by choos- 
ing from the bids submitted by the sellers. In Stage 2, the procured items are 



i £ M Seller agent 

N = {1, 2, ..., n} Set of buyer agents 
j G N Buyer agent 

K = {1, 2, ..., 1} Set of items 
k £ K Any item 

G = (Si, S 2 , •••} Collection of all multi-sets over K. 

SCG Any subset of G 

a(S, k) Quantity of item k in the subset S 

v(S,i) Value of the subset S to seller agent i 

v(S,j) Value of the subset S to buyer agent j 

y(S, i) Boolean variable indicating whether or not seller i gets the set S 

y(S,j) Boolean variable indicating whether or not buyer j gets the set S 



V = max 




s.t. 
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sold to the buyers so as to generate maximum revenue by choosing from the bids 
submitted by the buyers. This is described more formally below. 

Stage 1: We have assumed that the buyers are single minded. Therefore, we 
can aggregate the buyers’ demand. Let q k be the aggregate demand of item k, 
where 

ft = EE a(S,k)y(S,j) 

sakjeN 

The allocation problem for Stage 1 becomes: 

Vi = min ^2 E v ( S ’ i )y( S ’ i ) 

iCM SCG 

s.t. 

y(S, i) < 1 Vi £ M 

SCG 

EE a{S 7 k)y{S,i)>q k Vfc \/S C G 

S3k ieM 

y(S,i) = 0,1 V5CG,VieM 



This is precisely the formulation for reverse combinatorial auction for procure- 
ment as in [11] and in [7]. 

Stage 2: The problem in the second stage is to allocate to the buyers the items 
procured in the first stage to maximize the revenue of the exchange. The integer 
programming formulation of this stage is: 



F 2 = max E v ( S ’j)y( S ’j) 
jeN SCG 
s.t. 

EE a(S,k)y(S,i)<q k VkWSCG 

S3k jCN 

y(S,j) = 0,1 V5 C G,\/j G N 



We can immediately note that the above is an assignment problem and therefore 
can be solved exactly in polynomial time. 

We have thus decomposed the allocation problem of a demand aggregation 
combinatorial exchange into a reverse combinatorial procurement auction fol- 
lowed by an assignment problem. 

3.2 Supply Aggregation Combinatorial Exchanges 

Here the sellers declare to the exchange their individual total supplies and cor- 
responding reserve prices. We assume that 
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— the sellers are single minded. 

— the sellers submit atomic asks. But this can be generalized to other bidding 
languages such as XOR or OR*. 

Then the exchange asks the interested buyers to submit their bids for the aggre- 
gated supply. 

The notation for the supply aggregation exchange problem is given Table 1. 
The exchange can now be formulated as given below. 



V = max 

s.t. 



E E v ( S ’j)y( S ’i) ~ E E v (S,i)y{s,i) 



iGN SCG 



iCM SCG 



E y(s,j ) < i Vj g n 

SCG 



EE a(S,k)y(S,j) < EE a(S,k)y(S,i) \/k VS C G 

S3kjGN SskieM 

y{S,i) = 0,1 VS CG,Vi£ M 
y(S,j) = 0,1 VS C G,Vj e N 



Since the aggregated supply is known, we can decompose the above problem into 
two stages. In Stage 1, knowing the aggregated supply, we solve a combinatorial 
selling problem to sell the items to maximize revenue by choosing from the bids 
submitted by the buyers. In Stage 2, we procure the sold items from the sellers 
so as to minimize procurement cost by choosing from the bids submitted by the 
sellers. This is described more formally below. 

Stage 1: We have assumed that the sellers are single minded. Therefore, we 
can aggregate the total supply from all the suppliers. Let qk be the aggregated 
supply of item k 1 where 

® = EE a(S,k)y(S,i) 

S3k iGM 

The allocation problem for Stage 1 becomes: 



Vi =max^ v ( s J)v( s >j) 

jeN SCG 

s.t. 

E y( s ’j) ^ 1 v i e N 

SCG 

EE a(S,k)y(S,j)<q k Vk VS C G 

SBkjGN 

y(S,j) = o,i vscGyj e N 
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This is precisely the formulation for forward combinatorial auction discussed 
in [1] ] and in [19, 2]. 

Stage 2: The problem in the second stage is to allocate to the sellers the items 
sold to the buyers in the first stage. The integer programming formulation of the 
stage stage is: 



V2 =min E c ( S ’j)y( S ’j) 

jeNSCG 

s.t. 

EE a(S,k)y(S,j)>q k Vfc VS C G 

SBkjeN 

y (S,j) = 0,1 vscGyj e n 



Note that the above is an assignment problem which can be solved exactly in 
polynomial time. 

We have thus decomposed the aggregation combinatorial exchanges into 
a combinatorial auction followed by an assignment problem. Different mech- 
anisms have been proposed for combinatorial auction problems. We generalize 
the iterative Dutch auctions suggested in [11] for the aggregation exchange prob- 
lems. 



4 Combinatorial Dutch Auctions 
for Aggregation Exchanges 

We can extend the iterative Dutch auctions suggested in [11] for the aggregation 
exchanges as follows. 



4.1 Reverse Combinatorial Dutch Auction 
for Demand Aggregation Exchanges 

The exchange aggregates demands of all the buyers and also computes the max- 
imum price it is willing to pay for the entire bundle. Table 2 shows the notation 
used in the formulation. The proposed iterative mechanism consists of multiple 
bidding rounds denoted by t = 0,1,2,... ( t = 0 is the initial round). The ag- 
gregated bundle of all the buyers is therefore Bq. The exchange sets the value 
for W(B t ), maximum willingness to pay for the remaining bundle B t to be pro- 
cured in round t. The pricing of items is not linear, therefore the cost of the 
allocated bundles cannot be divided into price of individual items. Therefore 
we calculate pt , the average willingness of the exchange to pay for each item in 
round t. 

W{B t ) 

\Bt\ 



Pt = 



where B t ^(j) 
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Table 2. Notation for reverse Dutch combinatorial auction for demand aggregation 
exchanges 



B t 

Bo 

W (B t .) 
S t 

Pt 

V*{St ) 



v t 

|s| 



e 



Iteration (or bidding round) number 

Bundle to be procured in iteration t 

Total aggregated bundle of all the buyers’ demand 

Maximum willingness of the exchange to pay bundle Bt in iteration t 

Bundle procured in round t 

Average willingness of the exchange to pay for each item in round t 
Payment made by exchange for the subset St in iteration t. The 
payment is computed by solving GVA with reserve prices. 

Average payment made for any item in iteration t 

Cardinality of the set S 

Price increment per item in every iteration 



These average prices pt are not used in the auction mechanism but are used to 
prove the bounds given in Section 4.3. The payment made by the exchange for 
the subset S t in iteration t is V*(S t ). The average price paid by the exchange 
for each item procured is 



V*(S t ) 
I St 



We ignore the iterations in which no items are procured. 

The exchange sets the reserve price of the seller for any bundle S in iteration t 
as |5|u t _i. We use GVA with reserve prices [20] in each iteration to solve the 
allocation and payment problem efficiently. The bundle procured in round t 
is denoted by St ■ Therefore the integer programming formulation of the GVA 
problem with reserve prices in iteration t becomes 



V*(St) = max E E v(S,i)y(S,i) (1) 

ieM SCG 
s.t. 

y(S, i) < 1 Vi G M 

SCG 

EE a(S,k)y{S,i)>q k VkWSCG 

S3k iCM 

EE v(S,i)y(S,j) < W(B t ) VS CM 

ieM SCG 

v(S, i)y(S, i) > |S|«t_i VS C M,Vj e N 
y(S,i) = 0,1 VS C G, Vi e M 
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Table 3. Notation for the forward combinatorial Dutch auction for supply aggregation 
exchanges 



B t 

Bo 

W(B t ) 

S t 

Pt 

V*(St) 



v t 



t 



Iteration (or bidding round) number 
Bundle to be sold in iteration t 

Total aggregated bundle available from of all the suppliers 
Minimum ask price of the exchange for pay bundle Bt in iteration t 
Bundle sold in round t 

Average ask price of the exchange for each item in round t 
Revenue earned by the exchange for the subset St in iteration t. The 
revenue is calculated by solving GVA with reserve prices. 

Average revenue for any item in iteration t 
Price decrement per item in every iteration 



4.2 Forward Combinatorial Dutch Auction 
for Supply Aggregation Exchanges 

Here the exchange aggregates the supply from all the sellers and computes the 
total aggregated bundle and the minimum price at which it is willing to sell 
the aggregated bundle. Table 3 shows the notation for the formulation. In the 
combinatorial version of iterative forward Dutch auction ([11]), the seller starts 
with a high initial price and keeps on decreasing the price until the total bundle 
is sold. In the generalized Dutch mechanism for supply aggregation exchanges, 
the seller provides W(B t ), total ask for the remaining bundle B t to be sold in 
round t. We compute pt , the average ask price of the exchange for each item in 
round t. The average ask prices pt are not used in the auction mechanism but 
are used to prove the bounds given in Section 4.3. The payment earned by the 
exchange for the subset St in iteration t is V*(St). The average selling price for 
each item sold is 

V*(St) 

Vt |S t | 

We ignore the iterations in which no items are sold i.e. St^4> Vt. 

The reserve price for the remaining bundle St in iteration t is W(B t ). Also 
the maximum payment to the buyers for any bundle S in iteration t is 1 5 , |v t _ i . 
Therefore the integer formulation of the GVA problem with reserve prices in 
iteration t becomes 

V*(S t ) = min E ( 2 ) 

jeN SCG 
s.t. 

E v&i) < i vi e n 

SCG 

EE a(S,k)y(S,j)<q k Vfc VS C G 

SBkjCN 
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v(S,j)y(S,j) < |5|u t _! V5 C G, Vj e N 
EE v(S,j)y(S,j)>W(B t ) VS' C G 

jCN SCM 

y(S,j) = 0,1 vs c g, Vj e A 

4.3 Bounds for the Algorithms 

The second stage problem in both demand aggregation and supply aggregation 
exchanges can be solved optimally in polynomial time. Therefore the bounds 
for these problems depend only on the bounds of the first stage problems. Thus 
bounds for these mechanisms are same as the bounds given for iterative Dutch 
combinatorial auctions in [11]. 

Upper Bound for Reverse Dutch Auction and Demand Aggregation 
Problem: The upper bound for the iterative reverse Dutch auction is (1 + ^ + 
... + i)U(A), where 



V ( N ) = min EE Vj{S)y(S,j), and 

jGN SCG 

r = max 151 
Sck 1 

Lower Bound for Forward Dutch Auction and Supply Aggregation 
Problem: The lower bound for the forward Dutch auction is jV(N), where 

V ( N ) = max X £ vi(S)y(s,i) 
iCM SCG 



5 Numerical Experiments 

We have derived the worst case (lower or upper) bounds for these iterative Dutch 
mechanisms. We have run our algorithms on some of the test cases suggested by 
various authors [21, 22, 2, 23]. We have used CPLEX™ 8.0 to solve the various 
instances of GVA with reserve prices. 

5.1 Experiments for a Demand Aggregation Exchange 

We first conduct numerical experiments with demand aggregation exchanges by 
varying e and the number of agents i.e. buyers and sellers. Since we solve the 
second stage problem exactly, the solutions vary according to the results of the 
first stage. The trends in the graphs are therefore very similar to those obtained 
in the reverse Dutch auctions discussed in [11]. 

The graph in Figure 1 shows that the solutions tend towards actual optimal 
solutions as e tends towards unity. We also find the results of the approximate 
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Comparison of Solution of Two Stage Solution with the CPLEX Optimum 




Number of Sellers 



Fig. 1. Comparison of the demand aggregation results with the CPLEX optimum 
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Fig. 2. Computation time comparison with CPLEX 
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solutions are very good even when e is very small. However, we see from the 
graph in Figure 2 that the time taken to solve the problems grows exponentially 
when e is very close to 1. This happens because when e is close to 1 the problem 
we solve in the first iteration is almost the as hard as original problem. 

5.2 Experiments for a Supply Aggregation Exchange 

Numerical experiments with supply aggregation exchanges by varying e and the 
number of agents i.e. buyers and sellers are discussed in this section. In these 
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Comparison of Solution of Two Stage Problem with the CPLEX Optimum 




Number of Sellers 

Fig. 3. Comparison of the supply aggregation results with the CPLEX optimum 



Comparison of CPLEX Time with different EPS of Supply Aggregation 




Number of Buyers (Number of Sellers = 1/2 * Number of Buyers) 

Fig. 4. Computation time comparison with CPLEX 



experiments, we again solve the second stage problem exactly and therefore the 
solutions depend on the results of the first stage. The trends in the graphs are 
therefore very similar to those in the forward Dutch auctions discussed in [11]. 

The solutions tend towards the actual optimal solution as e gets close to 1 
(see Figure 3). But again the time taken grows exponentially when e tends to 1 
(see Figure 4). 
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6 Summary 

In this paper, we have studied a useful class of combinatorial exchanges where we 
can have demand aggregation (for example, procurement exchanges) or supply 
aggregation (for example, exchanges selling excess inventory). We have shown 
that the allocation problem in these exchanges can be decomposed into two 
stages: (a) Stage 1: Combinatorial auction (forward or reverse), (b) Stage 2: 
Assignment problem. Since the assignment problem in stage 2 can be solved 
exactly in polynomial time, we studied only the problem in the first stage. We 
have shown that the the iterative Dutch auction schemes proposed in [ 1] can be 
used for for solving the allocation problem in stage 1. This results in a compu- 
tationally efficient way of solving aggregation exchanges to obtain near optimal 
allocations. We have conducted numerical experiments to show that the pro- 
posed approach and algorithms perform very well and give results which are 
very close to the optimal solutions. 

The proposed approach can be used in all applications where aggregation 
combinatorial exchanges are relevant. The computational efficiency and the high 
quality of solutions will ensure that the mechanisms can be deployed in all practi- 
cal applications. Procurement exchanges, excess inventory exchanges, and stock 
exchanges are a few examples. 

In this paper, we have not considered game theoretic issues such as Vickrey 
payments, truthful bidding, etc. These are important issues that need to be 
addressed in future research. 
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Abstract. In this article we present a method to avoid security prob- 
lems in modern m-commerce applications. The security problems that we 
are addressing are breaches of security due to erroneous cryptographic 
protocols. We describe a specihcation technique that gives way to a for- 
mal, and thereby rigorous, treatment of the security protocols used in 
such applications. Security of communication is important in modern 
m-commerce applications. As parts of the specification of the security 
protocols, we describe how to specify the behavior of the agents, how to 
specify the attacker and how further aspects of the application reflect 
in the formal specihcation. The problem is that such formal specifica- 
tions are difficult to get right, so we propose a construction kit for their 
development. 



1 Introduction 

1.1 Mobile- Commerce 

Mobile-commerce applications appear in a large variety of forms. They can 
be customer-oriented (electronic selling of goods) or they can be intra- 
organizational (electronic business processes). Although the electronic selling 
is better known in the society, the mobile reorganization of business processes is 
getting more and more important. The devices used for m-commerce are man- 
ifold. Smart cards for high-secure applications, mobile phones or mobile digital 
assistants for smart mobile services or notebooks with mobile Internet access 
for heavyweight applications. Independent of the device used for the service, the 
requirements of m-commerce services are quite similar: Security of transmitted 
data, identification of the agents, exclusion of fraud. Yet these goals seem to be 
quite simple and even though they are claimed in all applications, realizing them 
properly is quite tricky. Differences in the application design, different possible 
forms of fraud in different applications and the large differences in the techni- 
cal features of the mobile devices result in securing an m-commerce application 
being a challenging task. 
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1.2 Security Protocols for Communication 

One important aspect of innovative m-commerce applications is the transfor- 
mation of business goods into digital data. Examples for such applications are 
electronic ticketing or electronic purses. It is crucial for such applications that 
the business goods cannot be manipulated or multiplied because this would per- 
mit fraud. For example, someone could increment the amount of money in an 
electronic purse. Another aspect is that m-commerce applications can require 
the transfer of customer data that must not be disclosed, e. g. credit card data 
or other personal information. Communication in m-commerce therefore means 
a lot of data that must be protected against different threats. The means for pro- 
tecting data and ensuring authenticity are cryptographic methods. For the dif- 
ferent functions of the application, security protocols (also called cryptographic 
protocols) must be developed that ensure the security of the data. The problem 
is that these protocols are very error prone [ ]. 

There are quite a few well-known security protocols that can be used to 
ensure many of the more common security demands (e. g. non-disclosure of 
the transmitted data and authenticity of the agents). One such protocol, often 
used in WWW-based e-commerce applications, is SSL [6]. The problem is that 
such standard protocols are not usable in all scenarios because they do not 
necessarily guarantee the application specific security goals. In smart card based 
applications, which are the main focus of the work presented here, the additional 
problem arises that smart cards do not offer the resources necessary to execute 
such standard protocols. 

Our work is a method for the specification and verification of cryptographic 
protocols for m-commerce applications and we therefore address the security 
problems arising from erroneously designed cryptographic protocols. 



1.3 Designing Secure M-commerce Protocols 

Cryptographic protocols are difficult to design. They may contain subtle errors 
that are not detected for several years (see [2] for examples). It is commonly 
agreed that formal methods give the highest assurance that the protocols are 
secure. This means that we can formally prove that a given protocol adheres 
to all required security properties (which must be given in a suitable mathe- 
matical description). As basis of such a formal treatment of security protocols, 
a specification that unambiguously describes the protocols is needed. 

However, creating such specifications is quite complex. The commonly used 
specification techniques are unsatisfying because they are either to detailed, for 
example the full EMV standard [5] or they lack a lot of relevant information, 
e. g. treatment of errors or checks of the data exchanged [2]. The formal proofs 
are surprisingly difficult, because an informal argumentation necessarily con- 
tains holes. And there is a graver problem: If the formal specification does not 
adequately reflect the real world, a ‘proof’ that a protocol is secure may be 
possible, but in the real world the protocol is not secure: In [2] the security of 
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a version of the Needham-Schroeder protocol is ‘proven’, but in fact the protocol 
was flawed [8]. Even an expert in formal methods is at risk. 

Therefore we propose a ‘construction kit’ to design formal protocol specifica- 
tions. While every application requires its own protocols and security properties, 
experience shows that the remaining parts of a formal specification can be stan- 
dardized. Using standard components reduces the risk of errors and allows to 
reuse previous proofs. 

1.4 A Construction Kit for Formal Protocol Specifications 

We propose a construction kit to design correct formal protocol specifications 
without much effort. The kit contains the following building blocks: 

1. A UML [10] class diagram for the agents in the application, and UML activity 
diagrams for the protocols (described in section 2). 

2. Security properties (described in section 3). 

These can be either class invariants or formulas of the formal specification. 
Additionally, the formal specification should be validated, i. e. it should fulfill 
some properties. These properties are: a successful protocol run is possible; 
and a modified protocol is insecure. The diagrams and security properties 
are specific for every application and must be designed by the application 
designer. 

3. One of three different attacker models (described in section 4): 

— An attacker that may receive and modify every message. 

— An attacker that receives every message, but cannot modify a message. 
— An attacker that cannot eavesdrop on or modify messages between other 
agents. 

4. The communication structure (described in section 5). 

This includes the number of agents, and the manner of communication. The 
more realistic this aspect is modeled the more complex the specification and 
proofs will be. However, a too simple model may be not an adequate model 
of reality. 

Some parts of the building blocks are generated automatically, some are taken 
from a library and a small part must be added by hand. The building blocks are 
unified in one large formal specification in which the correctness and security of 
the cryptographic protocols are proven. 



2 Modeling Applications 

In this section we describe our technique to specify the communication protocols 
and those parts of the application that contain data relevant for the security 
(most often the application logic but not the user interface) . A specification of an 
application consists of two parts, the description of the agents and the protocols. 
The agents are all the entities that play an active role in the application. They are 
represented by their internal state. Unlike the common descriptions of security 
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protocols we explicitly model the internal state of the agents. We therefore can 
describe which data is stored in each agent and when and how an agent modifies 
its state. Multiple agents of the same type are possible, similar to multiple objects 
that are different instances of the same class. The communication protocols of 
an application describe how the different agents work together, which messages 
are exchanged and which computations take place. 

Specifications that are written in a way that they are usable for verification, 
e. g. algebraic specifications, are hard to develop and require expert knowledge in 
formal methods. Our goal was to enable the application developer to contribute 
to the specification by using an UML-based approach. The scenario and the 
protocols are described in a graphical notation and are automatically converted 
into an algebraic specification. 

2.1 An Example 

The example we use to illustrate the specification is a simplified electronic purse. 
A user of this service can use special terminals to load money onto his smart card 
by inserting the smart card and the money he wants to load. Then the smart 
card stores the amount of money in the electronic purse. The smart card with 
the stored money can be used for payments of small amounts, e. g. in a canteen 
or in public libraries for using the copying machines. 

2.2 UML Diagrams 

We use two kinds of diagrams for the specification of an application. The state 
of the agents and the methods used to manipulate data are described in a class 
diagram. Class diagrams are mainly used in a standard manner and not further 
discussed. 

The protocols which describe the communication between the different agents 
are specified as activity diagrams. In general each function that is to be per- 
formed by the application requires its own protocol. The protocols define at 
what time what message is to be sent by which agent. Also the structure of the 
messages is defined by the protocols. Most important thereby is how the data 
is secured, i. e. what cryptographic primitives are used in what way. Figure 1 
shows one of the protocols of the electronic purse, the pay-function. This func- 
tion is used if the user wants to pay for goods or services and use the money 
on his card for it. The example application has another function, the function 
used to load money onto the card. This function has its own protocol which is 
omitted here. The diagram for pay contains two swimlanes, one for each agent 
participating in the protocol. The left swimlane represents the terminal, in the 
case of the pay-function this would be a merchant terminal, and the other swim- 
lane stands for the smart card. The protocols all start at the start-node in the 
terminal swimlane. In smart card applications the communication is always ini- 
tiated by a terminal, a smart card cannot begin an operation on its own. The 
course of events in the protocol is described by the control flow of the diagram. 
Activities stand for calculations being performed and for modifications of the 
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last _inst=instru ction.pay; 
challenge=generateNonceOi 
restNonceOi 
amount=arg.get _intO; 



col:document 



pay;accessdoc.mkdoc(documentlist.cons 
(access doc.intdoc(amount), 
documentlist.mklist(document.noncedoc 
(challenge)))) 



3 



[! (last _inst= instruction. pay)}/ 

[last _inst= = instru ction.payl 






> 



[! 

(accessdoc.decrypt(secretkey, 
arg)= = accessdoc.mkdoc(docu 
mentlist.cons(accessdoc.intdo 
c(amount), 

documentlist.mklist(documen 
t.noncedoc(challenge)))))] . 
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[accessdoc.decrypt(secretkey, 
arg)= = accessdoc.mkdoc(docu 
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rel:document 



[((am ou nt-arg . g etp aram (1). g et 
JntOXO) || 

(arg . g etp aram (1). g et _i ntQ< = 0) 



SW.DATA .INVALID 



SW.OK; acces s d oc. en crypt(s ecretk ey ,arg) 






Fig. 1. The Protocol for Payments 



state of the agent. A branch node is used for tests that have to be performed, 
e. g. correctness of received data, object nodes and the notes attached to them 
describe the exchanged messages. The path from the start node to the last end 
node describes the intended successful run of the protocol. Signal sending nodes 
and the other end nodes represent early ends of a protocol run, e. g. because of 
wrong data. 

2.3 Algebraic Specifications 

The graphical notation described in the last section is good for the specification 
process, because the notation enables non-experts in formal methods to con- 
tribute to the specification. Unfortunately, for the verification we need another 
description mechanism, one that contains the specification in the language of the 
theorem prover used. This theorem prover input is, in large parts, automatically 
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generated from the diagrams. In our case we use the KIV theorem prover [3] 
which works with algebraic specifications [7] and therefore the generation of the 
formal specification currently targets on algebraic specifications. Of course it 
would be possible to use other specification techniques, e. g. temporal logics or 
state machines. 

As a result of the automatic transformation process a structured algebraic 
specification is generated. An algebraic specification consists of a set of data type 
definitions, functions manipulating the data types and also predicate symbols. 
Combined with quantifiers we have a powerful formal description mechanism 
for software systems. The specification created from the diagrams contains the 
data types for the agents of the application, a document data type describing 
how messages are built in the communication and a function that describes the 
agents behavior in the protocols. 

Each agent is represented by its internal state, i. e. the value of all fields 
of the data type. When generating the data type for an agent, the fields are 
taken from the agents description in the class diagram. This explicit model of 
the internal state of the agents participating in an application is a significant 
difference to the other approaches for modeling and verifying security protocols. 
As we are ultimately aiming at a verified implementation of the application, we 
think that a model that is close to the actual software is better than the stateless 
descriptions in other modeling techniques. 

The function describing the agents behavior is the central part of the protocol 
specification. It defines for all agents how they react, i. e. what they answer and 
how they modify their state, if they receive a certain message. The function 

agent — says : (agent, document ) — > (agent, document ) 

takes the current state of an agent and the document the agent receives and 
returns the state of the agent after the modifications and the document the agent 
produces as answer. The axioms for this function are generated from the activity 
diagrams. Note that all the different activity diagrams are brought together in 
one function. This is due to the fact that each one of the activity diagrams only 
contains the information how the agents mentioned in the diagram behave in one 
specific function of the application, but for a description of an agent as a whole 
all these parts must be aggregated. 

A great deal of the algebraic specification can be generated automatically, 
yet some parts must be added by hand. It is possible to use methods in the 
activity diagrams describing the protocols (e. g. generateNonce () in Figure 1). 
These methods must be present in the class diagram, but only the signature can 
be taken from the class diagram and added to the specification. The semantics 
of these functions has to be added by hand. They are usually functions that deal 
with the treatment of data, e. g. a function storeTicket () to store a ticket in 
an array. 
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3 Security Properties 

Apart from the specification of the behavior of the agents in an m-commerce 
application we need two further ingredients in order to prove the security of the 
communication protocols. At first we need to know what exactly security of the 
protocols means in a specific application. This is discussed in this section. For 
the electronic purse the claim of the service provider would be that at no time 
the sum of the money spent with the cards is higher than the sum of all the 
money collected in the load stations. In the example, this property is expressed 
quite elegantly using two fields of the terminal to count the loaded and collected 
money: 

term. collected < term.issued 

This class invariant is translated into (the additional parts of the formula will 
be explained later) 

sec-glob : admissible(tr) 

— > \/n.tr[n\.env. term. collected < tr[n].env. term.issued 

This theorem guarantees that at no time more money is collected by the point- 
of-sales terminals than was issued by the load terminals. This rules out fraud 
because it cannot happen that money is spent that was not previously loaded on 
a card by a genuine load station. Other applications have completely different 
security claims. In an electronic shopping scenario, e. g. the customer would 
demand that his payment information (e. g. credit card data) is not disclosed to 
anyone other than the merchant. 

Finding, respectively determining, the security goals for an m-commerce ap- 
plication is part of the application design. The security demands, most certain 
at first just as some informal ideas, must be put in rigorous formalization to 
allow for their formal verification. Therefore the informal demands become log- 
ical formulas in the verification process. The theorems representing the security 
goals are the main object of the protocol correctness proofs. 

Besides the actual security goals some additional properties for the applica- 
tion should be proven. They can be seen as ‘sanity’ checks because they validate 
the specification. Most important are the following: 

— It is possible to successfully execute the protocols. This ensures that the 
specification of the possible traces is not malformed in a way that entirely 
disables the communication. 

— A insecure version of a protocol should be formulated and using this a suc- 
cessful attack should be proven. This ensures that the attacker is not acci- 
dently disabled by the specification of the possible traces. 

4 Specifying the Attacker 

The second building block that has to be added is the description of the threats 
the application is facing. The threats we are dealing with are not such unwanted 
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events limiting the availability of the service, e. g. hardware failures. Our focus 
are the threats resulting from accidental or deliberate misuse by one or more 
individuals. In the design and analysis of security protocols such individuals are 
usually called the attackers. To what extent an attacker poses a threat to an 
application is determined by his abilities. In security protocol analysis in general 
an instance of the Dolev-Yao attacker [4] model is used. This attacker is the 
most powerful attacker that still permits secure protocols. 

The problem is that such a powerful attacker is not realistic in all possi- 
ble application scenarios. Designing the protocols in a way that they are secure 
against the Dolev-Yao attacker always guarantees that the application is also 
secure if the real attacker is less powerful. Therefore we do not have a security 
problem but we have an economical problem. A more powerful attacker usually 
means that the security protocols must be more elaborate. They are harder to 
design and use more advanced cryptographic features. To make things worse, 
more advanced cryptographic primitives (e. g. asymmetric instead of symmetric 
cryptography) can necessitate more capable hardware. Additionally the usage 
of public-key systems could require the build up of a public-key infrastructure, 
which means a great deal of administrative effort. This all results in increasing 
costs. For example a smart card that can only perform symmetric cryptogra- 
phy is cheaper than a smart card with support for an asymmetric cryptographic 
algorithm. All in all we have the problem that an application can become un- 
necessary complex and expensive if an attacker is selected who is too powerful 
and therefore inappropriate for the application. 

Classical security protocol analysis generally assumes communication over 
a wide area network such as the Internet. Especially m-commerce scenarios make 
use of a wider range of possible communication channels: 

— Infrared (IrDA), 

— radio-based, e. g. Bluetooth for short-range and GSM for long-range com- 
munication, 

— LANs and WANs, 

— but also exclusive point-to-point connections, e. g. a smart card in a terminal. 

The different characteristics of the communication channels should reflect in 
the attacker model. This is another reason why a limitation to the Dolev-Yao 
attacker is not adequate. We therefore developed several other attackers with 
different abilities. They represent different levels of realistic adversaries in real 
life applications. 

4.1 Aspects Common to All Attacker Models 

Certain aspects of the attacker are common to all the attacker models we use. The 
central idea of the attacker is that he collects as much information as possible and 
tries to use the information he gathered to cheat on other agents. The information 
the attacker has collected is called his knowledge. The attacker’s knowledge 
is a set of documents that initially contains often just the attacker’s personal 
cryptographic keys but it grows when the attacker intercepts new messages. 
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One common aspect of the attacker models is how they treat the messages 
they obtain. A document that is received by the attacker is always added to 
his knowledge. But some documents are made up of sub-documents, e. g. an 
encrypted document contains the plaintext of the message as sub-document. In 
case of compound documents special rules apply. Not all sub-documents may 
go into the attacker’s knowledge. The process of adding additional documents 
to the attacker’s knowledge is specified using several functions (similar to [11]), 
most important: 



f+ computes a new set of documents by adding a document to a given set of 
documents and adding all documents that can be derived. If an attacker, with 
present knowledge docset, receives a document his knowledge is extended to 
docseto = docset f+ doc. Some other functions are used in the specification 
of f+ and explain how the new knowledge can be computed. In this process, 
the knowledge of the attacker is extended with all documents derivable from 
his present knowledge. What the derivable direct sub-documents of a document 
are depends on the document and the knowledge. For example a document en- 
crypted with key key , encdoc(key, doc), contains the plaintext as sub-document 
but this sub-document is derivable only if the knowledge contains the informa- 
tion necessary to decrypt messages encrypted with key: 

sub-enc-yes : 

can-decrypt(key, docset) — >■ sub-docs (encdoc{k ey , doc) , docset) = {doc}; 
sub-enc-no : 

-> can-decrypt(key , docset) — > sub-docs(encdoc(key , doc ) , docset) = 0; 

Note that the algebraically specified abstract documents can contain addi- 
tional information which their real counterparts do not contain, e. g. the key 
in an encrypted document. The information that is not contained in the real 
documents must of course not be a derivable sub-document. 

Also common to all attacker models is how they build new messages from 
the knowledge they have collected so far. They can guess non-confidential data, 
but they cannot guess confidential data such as nonces or keys. This means they 
can only use keys and nonces that they acquired by eavesdropping. Otherwise it 
would be impossible to ensure most of the common security goals. The attacker’s 
ability to derive documents is covered by a special predicate |= with signature 



docset |= doc states that the document doc can be constructed from the set of 
documents docset which contains the attacker’s knowledge. There are axioms 
for all kind of documents describing if they can be built given a certain set of 
documents. As mentioned above the attacker cannot guess keys, therefore he can 
build an encrypted document only if he possesses the key. This is covered by the 




documentset 



\= . : documentset x document 



axiom 
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encdoc : docset |= encdoc(key, doc) 

e-> encdoc (key, doc) £ docset 

V docset (= keydoc(key) A docset |= doc; 

and it states that the attacker can derive an encrypted document if the document 
is part of his knowledge or if the plaintext of the document and the used key 
can be derived from his knowledge. 

4.2 Attacker Models 

The Dolev-Yao Attacker The Dolev-Yao attacker model is the most powerful 
attacker model used. This attacker has complete control over the communica- 
tion, i. e. he can eavesdrop into every data exchange and manipulate all mes- 
sages traveling through the communication channels. The attacker decomposes 
all messages he intercepts and decrypts encrypted messages, provided that he 
has the necessary key. The attacker can arbitrarily generate messages from his 
knowledge. 

It is easy to see that it is not very common that someone has the abilities of 
this attacker. The attacker must have access to all agents participating in the 
communication . 

An Attacker with Limited Access to the Communication This attacker is devel- 
oped from the Dolev-Yao model by limiting his access to the communication. 
First of all this attacker can only eavesdrop into the data exchanges but he 
cannot manipulate the messages sent. This does not mean that he cannot par- 
ticipate in the communication at all. This attacker can still generate his own 
messages and send them over a communication channel as a regular participant 
of the service. Another possible limitation is that the attacker cannot eavesdrop 
on all data exchanges but just a few, i. e. he does not have control over the 
complete communication infrastructure but on some systems with an installed 
Trojan horse program. 

Prohibiting the attacker to manipulate messages is also necessary in order to 
prove certain reliability properties. For example it can only be guaranteed that 
an electronic railway ticket can successfully be presented to the conductor if the 
attacker cannot simply inhibit all communication by elimination of all messages. 
Availability of a service cannot be guaranteed with a Dolev-Yao attacker [9]. 

Attacker Without Access to the Communication This is the most restricted at- 
tacker we use. This attacker cannot eavesdrop on any communication taking 
place. What he can do is communicating with his own genuine device, e. g. his 
own smart card, and he can program a faked device, e. g. using a programmable 
smart card, that can be used to communicate with real agents and try to trick 
them into revealing interesting information. This is a quite realistic attacker. Ev- 
ery person with programming knowledge and a smart card reader is an instance 
of this attacker model. As the attacks that can be performed by this attacker do 
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not require great effort and are not expensive, attacks of this kind must be ex- 
pected in every m-commerce application, even if the possible gain of a successful 
attack is limited. 



4.3 Further Aspects 

What kind of attacker should be used in the verification of the application is 
a design decision that must be taken in an early step of the application devel- 
opment because it has a direct impact on the protocols and probably on the 
hardware selection. Some factors must be observed when trying to decide on the 
most realistic threat. In general one must anticipate more elaborate attacks if 
the result of a success is more severe. For example a smart card based credit card 
will attract more and technologically more advanced attacks than for example 
a loyalty card. 

There is another aspect of the attackers that must be kept in mind. It has no 
direct consequence for the formalization of the attackers but for the design of the 
security protocols. It is generally assumed that an attacker is trying to achieve 
a personal benefit by attacking a service. This is not necessarily true. When 
designing a service one should keep in mind that the service may have to deal 
with attacks whose only purpose is to annoy others, see e. g. denial of service 
attacks on the Internet. Preparing for such attacks is especially important if the 
availability of the service is crucial. 



4.4 In Brief 

The attacker is a very important concept in our treatment of security protocols. 
There are different aspects to be considered. In brief the following things are 
important: 

— How can the attacker decompose messages and build new ones. 

— Which communication channels can be eavesdropped by the attacker, which 
cannot. 

— Can the attacker replace messages in transfer by his own messages. 

— Does the attacker participate as a normal user of the service. (This is the 
case in most scenarios.) 

— Does the attacker use faked devices, e. g. a self-programmed smart card. 

— Does one attacker suffice or should a set of attackers be considered. 

— Is an ‘annoy only’ attacker relevant? 

5 The Communication Structure 

After modeling the protocols and the agents, and after selecting the attacker the 
communication structure remains to be modeled. This requires further choices: 
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1. The number of agents. 

It may be sufficient to consider only one attacker, one customer, and one 
merchant. This reduces the complexity of the specification and proofs con- 
siderably compared to one that considers an arbitrary number of agents. So 
this choice is desirable. On the other hand, there may be attacks against 
the protocol involving several agents, that are not possible otherwise. In this 
case the formal specification must consider an arbitrary number of agents. 
Otherwise the specification is not an adequate model of reality. 

2. The manner of communication. 

This can be either broadcast (one to all for radio based communication) or 
one to one, and may contain one channel or several. For example, there may 
be an ‘insecure’ radio based channel like WAP and a ‘secure’ channel based 
on GSM. Again, the choice influences the complexity of the specification and 
proofs, and how adequate the formal model is. 

3. Interleaving of operations. 

Is it adequate to assume that every software component immediately an- 
swers to a received message? Or is it necessary to assume that things can 
happen interleaved or even in parallel? Since we are dealing only with the 
logical properties of the protocols the first possibility is sufficient. However, 
one agent may have exclusive access to a communication partner. (E. g. a 
terminal to a smart card if an attacker without access to the communication 
is used.) 

4. Occurrence of state changes. 

Every agent has an internal state. This is important when the specification 
is refined into an implementation. If interleaving is used an agent receives 
a message and some time later issues an answer. Usually, the internal state 
is modified. The question is when? When a message is received, when an 
answer is issued, or sometimes between? 

With these choices the formal specification can be completed. An environment 
contains all agents with their internal state, an event consists of an environment 
and a communication between two or more agents, and a trace is a sequence of 
events. A trace is admissible if all agents adhere to their specified behavior. In 
the electronic purse example this means that the smart card, the load stations 
and the pay stations follow their protocols, and that the attacker sends only 
messages that are derivable from his knowledge. An admissible trace can be 
viewed as a sequence of events that can happen in the real world. Consequently 
the security properties must be proven for all admissible traces (see sec_glob in 
section 3). The definition of admissible can be divided into several parts that 
are to some degree independent of each other: 

admissible (trace) 

<-> attacker_admissible(trace) 

A protocoLadmissible(trace) 

A state_admissible(trace) 

A ... 
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For example, attacker_admissible(trace) may look like: 

attacker _admissible([ev, ev 0 , trace]) 

<-> (ev.from = attacker — > ev.env. known (= ev.doc) 

A (evo-to = attacker — > ev.env. known = evo.env. known f+ evo-doc) 

A (evo-to attacker — > ev.env. known = evo.env. known) 

A attacker .admissible ([evo, trace]) 

Here, a trace consisting of a last event ev, a previous event evo, and a remaining 
trace is considered. (For verification purposes the first element in a trace is the 
last event that occurred.) The first part of the axiom specifies that if a document 
is sent by the attacker (ev.from = attacker), he must be able to generate it from 
his knowledge (ev.env. known |= ev.doc); the second part specifies that if he 
received a document (ev 0 .to = attacker) in the next to last event it is added to his 
knowledge and all derivable documents as well (ev.env. known = evo.env. known 
/+ ev 0 .doc) so that the knowledge is present in the last event; the third part 
specifies that if the document is not sent to the attacker his knowledge remains 
unchanged. This implies an attacker without access to the communication. 

protocol_admissible (trace) specifies that if a normal agent issues a message 
in event ev it is the answer to a received document in some event evo and follows 
the protocol as defined by agent-says: 

protocol-admissible ([ev, trace]) 

<-> ( ev.from y^ attacker 

— > 3 ev 0 € trace: agent-says(ev 0 . agent, ev 0 .doc) = (ev. agent, 
ev.doc) 

A evo = matching_event([ev, trace])) 

A protocoLadmissible(trace) 

If interleaving is used event evo is not necessarily the next event, but can occur 
somewhere in the trace. This must be specified with matching_event. Further- 
more, the axiom does not define the internal state of the agent between the two 
events, or when the state changes. The predicate state_admissible specifies that 
the state of all agents that do not participate in a communication remains un- 
changed. Further predicates are needed to specify the communication structure 
exactly. 

The problem is that the different building blocks described so far cannot be 
specified completely separate. Actually, they are interwoven and may contain 
subtle interactions. This means it is very easy to introduce errors if the spec- 
ification is written ‘by hand’. A faulty specification is not an adequate model 
of the real world. In the best case it is not possible to prove that a protocol is 
indeed secure. In the worst case a ‘proof’ is possible for an insecure protocol. 
For example, the axioms used to describe admissible traces may be inadvertently 
contradictory (one axiom may say that a state change must occur, another that 
a state change may not occur). In this case there are no admissible traces (in 
the formal model) and every security property is trivially fulfilled. Especially the 
combination of interleaving and exclusive access to an agent is very difficult to 
specify correctly. 
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6 Conclusion 

In this paper we discuss questions concerning the security of m-commerce appli- 
cations. We introduce a method to avoid security problems by formally analyzing 
the application. The problem is that building a formal model is difficult and it 
is easy to introduce errors. Therefore we propose a ‘construction kit’ that allows 
an automatic generation of large parts of the specification. The kit consists of 
several parts: We describe how security protocols can be modeled. We also de- 
scribe different attackers relevant for m-commerce applications. It is described 
what different abilities these attackers posses and how some of these abilities 
are represented in an algebraic specification. We also discuss further aspects 
that influence the modeling of the application and especially how these factors 
influence which traces (list of events) are possible and which not. 
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Abstract. Peer-to-peer markets going mobile spur spontaneity in trad- 
ing considerably. Spontaneity, however, imposes severe informational re- 
quirements on the market participants. Informational requirements are 
twofold: Firstly, participants have to agree on a common vocabulary for 
that spontaneous market. Secondly, they need precise information about 
how the trading process is organized. Due to the lack of a central market 
operator these common understandings must be determined by the mar- 
ket participants themselves. Prior to any market process, these terms and 
regulations must be distributed by the market participant that initiates 
the market process. This raises the question concerning the used ontol- 
ogy. Standards describing (business) processes are available in general, 
but are currently not suitable for ephemeral markets. Electronic markets 
are extremely context sensitive, making the establishment of common 
understandings crucial as well as difficult. This paper uses structural 
similarities of markets and creates a Minimal Market Model. Since this 
model is for all conceivable markets constituent, it can be used as the 
core component. As any market is founded on this minimal model, it 
can be systematically extended to capture the peculiarities of each par- 
ticular market. The derivation of the Minimal Market Model is founded 
on a solid ground of economic theory and refined such that it can be 
expressed in a formal way. 



1 Introduction 

With the rapid technological progress of mobile ad hoc networks (MANET) [1] 
and wireless devices with sizeable graphical user interfaces (GUI) (like Smart- 
phones, PDAs communicating wirelessly, etc.) mobility in markets has recently 
become a very important and attractive issue. The innovation and technology 
affinity of electronic market participants and the continuing trend towards total 
mobility in work and lifestyle only add to this significance. Yet, most electronic 
markets still rely on client-server-technology with a persistent infrastructure. 
Just rudimentary attempts have been made to establish mobile markets. Trans- 
ferring the market GUI to mobile clients that still access the same steady server 
can only be considered a first start. 

Ephemeral markets are markets that arise and fade spontaneously. They are 
typically short-lived and often based on a peer-to-peer (P2P) structure as well as 
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MANETs. The combination of the latter two paradigms enables truly decentral- 
ized mobile market structures that challenge the client-server-approach. They 
show promise to add to the variety of markets and to develop new application 
areas, but still require substantial research. 

To advance the establishment of mobile markets, this paper provides a the- 
oretical fundament for market models applicable to ephemeral markets. This 
brings together Economics with Computer Science concepts. Section 2 intro- 
duces ephemeral markets and identifies their economic challenges relevant for 
application. After related work is presented in section 3, section 4 presents the 
Minimal Market Model and the methodology for market modeling it implies. 
Section 5 proposes and examines the application of respective market models to 
ephemeral markets in order to tackle the crucial aspects of section 2. Section 6 
briefly summarizes the presented work and gives an outline for future work. 



2 Economic Characteristics of Ephemeral Markets 

Traditionally, the discipline of Economics has been devoted to the study of mar- 
kets. From the beginning, markets have been viewed as a coordination mecha- 
nism [2]. However, Coase concludes that in modern economic theory the market 
itself has ” [...] an even more shadowy role than the firm. [...] In the modern text- 
book, the analysis deals with the determination of market prices, but discussion 
of the market itself has entirely disappeared” [3] . Characterizing markets as the- 
oretical constructs in neoclassical tradition is not sufficient, as it provides only 
a functional definition of the market (a market is what a market does). It es- 
pecially ignores the notion of transaction costs that exist in real-world markets. 
Based on this intuition, New Institutional Economics has bred out a more com- 
prehensive definition than Neoclassical Theory. Accordingly markets describe 
the institutional rules how the market price is formed. With this definition in 
mind, economists have developed a causal theory about the working of markets 
including informational asymmetries and principal-agent problems. 

When markets turn mobile, providing contextuality becomes crucial 1 . Con- 
textuality comprises in what way and in what circumstances mobile agents 
act [4]. It is the mobility dimension most relevant for the economic challenges 
in ephemeral markets. These challenges arise from three major aspects of P2P 
markets based on MANETs: 

1. Spontaneous participation 

Participants arbitrarily enter and leave a market. They appear without any 
prior market knowledge and leave taking all their information with them. 

2. Spontaneous evolution 

Markets are created spontaneously by any participant and fade when every 
involved individual leaves the particular market. 

1 Kakihara and Sprensen identify three dimensions of mobility, namely spatiality, tem- 
porality and contextuality. [4] 
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3. Lack of a distinguished persistent entity 

There is no distinguished entity that could continuously cache and provide 
information. 

These three aspects combined hamper the establishment and maintenance 
of a constant and common contextuality. The biggest challenge is to inform an 
agent about the structure of the concrete market he is about to join. 

In traditional markets a distinguished persistent entity usually exists and is 
trusted by all participants. This solves the problems arising from spontaneous 
participation and prevents spontaneous evolution. Information about the respec- 
tive market - especially for new participants - is provided by the trusted distin- 
guished entity. To a great extend, this information is presented and only exists 
in an implicit or informal way: Traditionally, the description of an electronic 
market is communicated as a combination of rules buried in code and one or 
several natural language documents. The software confronts the user with most 
market requirements by the entries it accepts and the information it reveals. 
The underlying structure is implicit and requires a lot of user experience to be 
extracted. An eventual additional description in natural language relies on the 
description skills and willingness of the author as well as a competent interpre- 
tation by the participants that can hardly be automated. As such, it supports 
no coherent theoretical foundation that guarantees or at least promotes a com- 
plete coverage of all relevant market aspects. In particular, the implicitness of 
information severely hampers an explicit analysis and comparison of the implied 
market specifications. 

Since market participants always base their strategies on their understand- 
ing for one market, an explicit, formal, coherent and well-founded description for 
the market conditions is desirable in any kind of market. For ephemeral markets, 
however, such a representation is indispensable, because agents can hardly rely 
on a closed, rigid and untraceable implementation without further specification. 
They rather require easy perceivability of any particular aspect of trade with as 
little previous knowledge required as possible and rapid reconciliation of market 
protocols. 

3 Related Work 

A multitude of different terminologies as well as description approaches for mar- 
ket structure exists, both in the research and the industry sector. Taking part 
in markets - either electronic or face-to-face - always requires from all mar- 
ket participants to share a common understanding of trading specific terms and 
structure. Principally, there are not that many basic concepts and interrelations 
required, but the parallel development of proprietary standards in different fields 
and domains has bred out the mentioned multitude of variants. 

eBay as one well-studied realization example of a market model requires 
from each participant to understand the underlying terms (buyer, seller, bid, 
etc.) used on its web pages 2 and the rules of the auction (bids with increasing 



2 http://www.ebay.com/ 
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price, fixed time closing rule, etc.). A market model in general defines all insti- 
tutional rules that regulate the functioning of an electronic market (e.g. bidding 
language, bidding process rules, price and allocation rules). For eBay at least 
three different approaches to terminology and structure description of the auc- 
tion market model existfrom the research side. They range from ’’English auction 
with proxy bidding” [5] over ” Second price auction” [6] to parametric description 
of components, like matching and allocation [7]. These descriptions - although 
totally different - all refer to the same market model. Even more difficult, the 
used terms and interrelations of market models are context-sensitive and often 
differ from industry to industry. 

Principally, the problem of reconciling and coherently describing a com- 
mon market model in ephemeral markets resembles the interoperability problem 
known from B2B electronic commerce. The interoperation between systems of 
different corporations requires a common understanding of the exchanged data 
and an agreed-upon protocol for data exchange. This requires syntactic as well 
as semantic interoperability. 

On the syntactic level a mutually agreed-on vocabulary is needed to build 
the market model on this foundation. In B2B electronic commerce, the market- 
place providers mostly dictate their own languages like xCBL (Commerce One), 
cXML (Ariba) or OAGIS (Open Application Group) [8, 9]. Those standards, 
however, do not encourage the reconciliation of conflicting terms from differ- 
ent backgrounds. They are mainly aimed at the interconnection of terminology- 
compliant ERP systems and not towards the use in spontaneous markets. 

On the semantic level a common understanding of (business) processes and 
interrelation between terms is necessary for all market participants. Starting out 
with the open-edi initiative in 1988, the business transaction was split into two 
views - one for business properties and another for technical properties. Both 
views help different companies to define the same product in exactly the same 
way. In the open-edi tradition the RosettaNet Implementation Framework de- 
fines an exchange protocol, and the Message Guidelines, while the latter give 
instructions on how to encode individual partner interface processes into specific 
packages [10]. While RosettaNet is domain-specific for the IT industry, ebXML 
contributes a domain-independent global standard for communication between 
businesses and specifications for business processes. In essence, ebXML provides 
an open architecture to define business messages, communicate messages, con- 
duct trading, and define and register business processes. By means of ebXML 
companies can describe their business processes in a specified manner and reg- 
ister them (i.e. XML documents). ebXML also provides a mechanism to match 
companies with the same business processes [11, 8]. 

In essence, a market model can also be perceived as providing a business pro- 
cess, namely for the market operator [12]. In ephemeral markets there does, how- 
ever, not exist a central market operator. As such the market participants must 
themselves agree upon a market model. Current attempts to provide a common 
market model definition are mainly on the syntactical level. For example Wur- 
man et. al decompose auctions into their institutional rules, which are treated 
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as parameters [13, 14]. To define an auction a list of parameters needs to be 
specified for configuring the market model. By varying the specifications of the 
parameters other auction formats can be configured. As such, the configuration 
space of auctions that can be described parametrically is rather huge. Strobel 
and Weinhardt extend Wurman’s work from auctions to negotiations [15]. An 
abstract version of those definitions can be found at Maekioe and Weber [16]. 
The definition of the market models typically follows a top-down approach trying 
to encompass every imaginable market detail a priori. All parameters in a list 
that is given beforehand must be specified for a valid market model. Even if 
parameters are oblivious for a specific market, these approaches require every 
parameter in the list to be regarded. On the one hand, this hampers the spon- 
taneous establishment of new market models essential for ephemeral markets. 
On the other hand, even an extensive parametrization approach still limits the 
number of market models that can be configured. 

Thus, in the following, a bottom-up approach is motivated. Instead of iden- 
tifying all conceivable parameters of the market model on the syntactical level, 
only a minimal set of interrelated core concepts - the Minimal Market Model 
- is presented. This merely needs to be refined in the - possibly few - aspects 
particular for one spontaneously initiated market, since the basic semantics re- 
main the same for all particular market models. In this manner, the Minimal 
Market Model can be systematically extended to cover any market imaginable. 
The functional structure of this bottom-up approach makes a multitude of - 
potentially synonymous - tags or verbal descriptions obsolete as identifiers. For 
instance, the ’’English auction with proxy bidding” on eBay will be represented 
by a model identical with the one for the ” Second price auction” that also refers 
to eBay. Thus, the ambiguities between existing standards are eliminated. 



4 The Minimal Market Model 

The Minimal Market Model (MMM) offers a semantic perspective on markets 
and a core of market conditions. Its structure suffices to capture the essential 
aspects within a market. But, beyond that, it forms the basis for systematically 
developing more specific market models. The MMM is presented as a theoret- 
ical approach in this section. The formalization aims at computer processing. 
But only in the following section 5 will the MMM be introduced to implemen- 
tation. The main contribution is the theoretical look below the surface in order 
to identify the underlying structures of markets. This paper abstracts from any 
execution, enforcement, representation and media aspects including the actual 
realization of market communication, the technical infrastructure, etc. 

The MMM is based on the following notion of intentional reasoning [17]: 
Trading occurs, because the participating agents perceive a trade as beneficial. 
Their intentions and the intrinsic motivation to realize these are the driving force 
for trade. In this context, a market is the impartial structured condensation of 
participants’ intentions into exchange agreements. Therefore, intentions have to 
be uttered. The market process is characterized by patterns and market models 
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intend to capture the structure of these patterns. Besides this descriptive aspect, 
market models can also be used to prescribe patterns for markets. Some patterns 
are required for every market, namely that intentions are characterized by their 
associated participant and the products the latter intends to give away and re- 
ceive in exchange. Products are described by - potentially complex - attribute 
structures. Agreements can only be reached, when the constituting intentions 
match. These essential requirements are common to all markets and reveal their 
very essence. When assembling a market model, they can serve as a starting 
point and always outline the minimum conditions. The minimal structural de- 
scription is tightened in the Minimal Market Model that is presented in the 
following subsection 4.1. Our notion of minimality implies that a market based 
strictly on the MMM has the least restrictions required for a market. This also 
means minimum restrictions on the strategy space of market participants and 
therefore maximum freedom for them. It implies that every essential aspect of 
markets is included and no superfluous or redundant information is represented. 
That leads to a very compact model with all of its elements indispensable. It 
appears in a manageable guise, but nevertheless its instances contain a wealth of 
dense information. Thus, the crucial function of the Minimal Market Model is to 
provide a complete, compact and coherent representation of the characteristics 
of the market nature. 

4.1 Statics of the Minimal Market Model 

Building on the deliberations above, we shape the heart of the MMM. The five 
elementary concepts, also called classes, within a market are the following: 

intention 

An intention represents the smallest closed entity of purpose within a market. 
It can be binding, which means that it is committed to the exact fulfillment 
of the expressed purpose. If it is not binding, it merely reveals information 
relevant for the market and does not in any way represent commitment nor 
the will to commitment. 

An intention is specified by adjacent instances of the three following classes. 

participant 

A participant represents an agent of any kind that takes part in the market. 
This can be a software agent, a human individual or any other entity capable 
of having intentions. 

Participants must have at least one intention in a market, but can have more. 

product 

A product can represent any good (including physical and digital ones, trans- 
ferable rights, money, engagements like those for employment, ...) or service 
that can be traded within a market. 

It is associated with exactly one intention. And it always has either the role 
of an incomingProduct or an outgoingProduct, while incoming and outgoing 
refer to the perspective of the participant that is connected to the product 
via an intention. Every intention is associated with one or more incoming 
and one or more outgoing products. 
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attribute 

One or several attributes describe the properties of products. Complex struc- 
tures are accounted for by allowing attributes to have subattributes, since 
product description can be a very elaborate and crucial task in market mod- 
eling. 

An attribute can be declared forMatclring. This means that the respective 
attribute is considered when matching the underlying intention with oth- 
ers. This requires other potentially matching intentions to also represent the 
statement of the respective attribute in a forMatching state. An attribute 
that is not forMatching provides information about the respective product 
but is uot regarded for the matching in the market. An attribute is asso- 
ciated with at least one product. If it connects several products they must 
be associated with the same intention. Attributes spanning more than one 
product are used to represent interdependencies between the products, 
agreement 

An agreement is always derived from two fully specified intentions that are 
declared binding. It indicates that the two associated intentions match and 
that the respective participants have committed themselves to exchanging 
the products of the involved intentions. 

These five concepts and the respective interrelations constitute the core of any 
market structure. Conditions for further interrelations are the following: Existing 
products and participants are always connected to one or more intentions, and 
an intention always needs one participant and one or more products associated. 
Every product connected with an intention is classified as either an incoming- 
Product or an outgoingProduct. Incoming and outgoing indicate whether the 
associated participant intends to give a product away or to receive it. Combin- 
ing incoming and outgoing products in one intention means that the respective 
participant wants to trade all outgoingProducts for all incomingProducts in one 
deal. This allows for product bundles. It appears that the attributes only refer 
to products. Of course, the other concepts’ properties are also described with 
attributes, but they can simply be embedded in the respective classes. The com- 
plex attribute-subattribute structure is generally not required for these concepts. 
If need be, though, it can also be attached to them. 

It is crucial to keep in mind the distinction between the theoretical level of 
the MMM and the perceivable layer of markets in practice. For example, an 
intention, abstract by nature, can manifest in a multitude of ways ranging from 
vegetables with a price tag on a stall, over printed catalogs, or purchasable files 
presented on a website, to offers in structured electronic documents. The sheer 
raising of a hand for bidding in a real-life English auction epitomizes a full inten- 
tion. It implies that the person attached to this raised hand intends and signals 
that she is willing to take the product at stake in exchange for the announced 
amount of money. The intention per se is, of course, not visible in the practical 
setting, but precisely defined in the context of the market model and the history 
of preceding intentions. The vivid variety of real life is brought down to the 
intention structure in theory. 
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Fig.l. UML Class Diagram for Market Statics 



Although intentions can represent preferences 3 - that are also theoretical in 
nature - they are not identical with these. A preference is internal, passive and 
not necessarily associated with the immediate will to act that is necessary for 
markets. An intention, however, is an active element that is consciously brought 
into a market. It does not have to represent a fully specified preference, but 
can leave some aspects, namely attributes, open for completion. Fully specified 
intentions, however, always express preferences, since the respective participant 
is willing to give away the specified outgoingProduct(s) in exchange for the in- 
comingProduct(s). For rational agents this implies that they prefer what they 
receive over what they give away. All these aspects are static since their instan- 
tiation can only capture the state of a market at one given moment in time. Any 
aspect that is related to change over time is not regarded, yet. 

To give an overview of the static aspects, the Unified Modeling Language 
(UML) 4 class diagram of Figure 1 depicts the static hull of a market, namely 
its elementary class types and their associations including cardinalities and role 
names. 

In addition to Figure 1 some static axioms apply that implicitly have been 
introduced above. The following list pulls them together and gives a short ex- 
planation for each: 

Intentions must be binding to be able to constitute an agreement 

The binding-flag in the intention class must be set to true before an intention 

can constitute an agreement. 

— Intentions must exactly match when constituting an agreement 

Agreements require matching in general: 

• The outgoingProduct of one intention must be equal to the incoming- 
Product of the partner intention and vice versa. 

• Every aspect specified by the attributes of a product with forMatching 
set to true must also be specified for the corresponding product of the 
other intention involved. 

Agreements further requrire exact matching in the following sense: 

3 In Economics preferences are used to express how alternatives are related to one 
another. For instance, an agent might prefer bundle a to b. [18] 

4 http://www.uml.org 
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Fig. 2. UML Object Diagram of Market Snapshot 



• Every attribute must make one statement and not allow for any choice of 
alternatives. E.g. it must represent one single value as opposed to a range 
or set of values. 

• The unequivocal statement of one attribute forMatching must be iden- 
tical to its equivalent describing the corresponding product of the other 
intention involved. 

Aspects specified by an attribute-subattribute combination do not necessarily 
have to appear in the same shape; only the meaning as well as the forMatching 
status must be equivalent. This may require rather complex matching methods. 
Yet, they can be kept simple by predefining the structure of attributes for con- 
crete settings. 

Figure 2 depicts a UML object diagram to give an example of what instances 
of the class diagram look like. According to the UML specification [19] it ’’shows 
a snapshot of the detailed state of a system at a point in time” . Some association 
names and all attribute names are not displayed for the sake of clarity. 

The exemplary snapshot in Figure 2 depicts two participants in a market 
for digital photo cameras. They have just accepted the agreement that F.A. 
Hayek will give his product D70, manufactured by Nikon and currently located 
in London, to J.M. Keynes in exchange for 1000 euros. J.M. Keynes has the non- 
binding intention to sell his camera Canon PowerShot Prol. He would therefore 
accept euros or dollars. 

A complete snapshot of a market comprises every instance of every class that 
is relevant at the time of the exposure. Naturally, not all instances have to be 
connected via association instances. 



4.2 Dynamics of the Minimal Market Model 

The static aspect is not sufficient for tracing the action within markets. It takes 
a series of snapshots that results in a market movie - to stay in the image. Every 
such market movie covers all information available in theory for the respective 
market. Therefore, it must contain a snapshot with a time stamp for every update 
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Fig. 3 . Exemplary Market History Excerpt 



within the market. An update event is triggered whenever a new intention arises, 
an old one fades, an existing one shifts, an agreement is reached, etc. So, a market 
is represented by a history of instances of the class diagram as shown in the 
following Figure 3. 

Figure 3 shows an example of three subsequent market snapshots ton, t -072 
and fo 73 - All information new in a snapshot is shown in black; the remaining 
relevant information from the preceding step(s) is displayed in grey. 

At to 7 i the market participant F.A. Hayek has made a binding offer for a cam- 
era he is willing to sell for 1000 euros. The camera is located in London, has the 
name D70 and the brand Nikon. J.M. Keynes signals his non-binding intention 
to buy a Nikon D70 camera and to pay for this in euros. At fo 72 J.M. Keynes 
concretizes the amount of euros he is willing to pay to 1000 and declares his 
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intention binding. At <073 both participants reach an agreement based on their 
intentions which therefore must and do match. 

Within the time dimension markets gain profile as the evolution of the snap- 
shots also follows certain patterns. The structures for the development of inten- 
tions and agreements over time have to be added to a market model to describe 
the respective market’s character as thoroughly as possible. They imply a re- 
stricted strategy space of the market participants and thereby limit the set of 
possible market movies within a more concrete market model. Consequently, 
these conditions go beyond the scope of just one market snapshot and (logi- 
cally) span several snapshots within the history of one market. The static aspect 
of the MMM provides a closed basis for the dynamic market conditions. The 
concepts in section 4.1 plus the time are all the variables needed for any market 
microstructural specification. For the case of minimality only one very simple 
dynamic condition applies: Ex post, at least one agreement between two 
different participants must exist in the history of market instances 

No strategy space restrictions exist beyond the ones presented so far. Thus, 
in a completely unconstrained - that is minimal - market, any participant can 
express any model-compliant intention at any time. 



5 Implications 

The MMM as presented is a concluded specification of the essential market con- 
ditions and captures the nature of markets. Any snapshot movie complying with 
the MMM depicts a market. Any instance that fits in a specific market model 
belongs to the respective market. 

Furthermore, the MMM is a fundament for deriving the models for spe- 
cific markets. On the static level, subclasses can inherit from the concepts of 
the MMM, to introduce the product categories, participant groups, etc. of one 
specific market. When talking about a domain market, for example the ’’cam- 
era market”, a camera market model could derive the subclass ’’digital photo 
camera” from the product concept in the MMM. The European camera mar- 
ket model could further derive an explicit and mandatory location attribute for 
products and restrict its values to European cities. On the dynamic level, the 
most interesting phase lies between the stages where multiple intentions match 
and where the agreement based on two of the matching intentions is reached. 
This phase is called allocation. 

In the minimal setting any agreement requires the explicit acceptance of the 
involved participants. In some specific market models, allocation rules automate 
the acceptance of the participants when the latter commit themselves to these 
rules. In contrast to the matching conditions that merely scrutinize intentions, 
allocation rules can actually concretize alter intentions. For the minimal set- 
ting we will further assume that allocation merely means explicitly accepting 
an agreement. But for specific markets, the matching conditions can be refined 
and allocation rules added. This can result in the specification of auction types. 




A Minimal Market Model in Ephemeral Markets 



97 



Again, more structure will narrow the use of the resulting model to a subset of 
markets, for example a class of auctions. 

The MMM does not restrict the visibility of information for any participant, 
since information revelation is not limited in a minimal market. However, in- 
formation in concrete markets is often explicitly restricted for most (groups of) 
market actors and respective rules will have to be included in specific market 
models. 

6 Application Issues for Market Models 
in Ephemeral Markets 

For the application of market models this section will examine the challenges 
that occur when implementing any market model - including the MMM - in 
practice, independent from domain specifics. Addressing the issues of market 
model refinement and specific domains is beyond the scope of this paper. 

For general implementation issues of market models the notion of market- 
places has to be regarded. A marketplace can be seen as an imaginary delimited 
container that restricts the matching of intentions. In theory (section 4) an om- 
niscient auctioneer sees all instances within a market and can identify matching 
intentions, etc. However, the marketplace notion restricts the overall view for 
the matching and that of any agent to one container. What an agent can do is 
observe several containers, but joining the information gathered as well as possi- 
ble functionality spanning multiple containers is up to him. To post intentions in 
a container, they are made explicit in offers. Only intentions whose offers meet 
within the same container can practically match. One intention can be expressed 
with more than one offer and the latter can be sent to different containers. So, it 
is possible to either distribute one intention to multiple offers, e.g. for bundles, or 
to express an intention repeatedly. If independent intentions that underlie offers 
in different containers match according to a given market model, they belong 
to the same market. Yet, the respective offers do not match in practice due to 
the separation between the marketplaces. Consequently, agreements can only be 
reached based on two intentions that are in the same container, i.e. on the same 
marketplace. So, the market, cohesive in theory, is usually distributed to several 
marketplaces in practice. In ephemeral markets we regard all nodes that share 
the market specification and are connected in a communication network as one 
marketplace. 

Distributing the MMM to all potential market participants suffices to deliver 
a common understanding of the essential market notion. For the characteristics 
of a certain market, a specific market model including refined products, addi- 
tional matching and allocation conditions, etc. can be derived from the MMM. 
This specific model alone delivers a common understanding for markets - as it 
includes all minimal information from the MMM - and at the same time informs 
the potential participants about the concrete market details. For transmission, 
the models need to be formalized in a serializable way. Ontologies [20] are one 
representation method suitable for all aspects of the MMM. They also provide 
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the possibility to describe synonyms and homonyms that tackle the problems 
of conflicting terminologies (cp. section 3). Ontologies can be represented in the 
web ontology language 5 (OWL) that is XML 6 based and therefore serializable. 
Instances can be created from an ontology representing the MMM. They can be 
sent as offers and used for matching. 

So, the required knowledge about market processes and the interfaces is 
clearly defined and formalized by the ontology in a machine-readable way. Any 
kind of client can now be used for the market as long as it complies with the pro- 
vided specification. The self-concluded specification allows for everything from 
individual clients for each participant developed in proprietary environments to 
a light-weight and flexible common client automatically and traceably adapting 
to different specifications. 

Yet, we still have to take a closer look at the three aspects crucial for contex- 
tuality in ephemeral markets, namely spontaneous participation, spontaneous 
evolution and the lack of a distinguished persistent entity (cp. section 2). 

Spontaneous participation is supported by the introduced methodology of 
modeling markets. Firstly, a concrete market model that is a systematic refine- 
ment of the MMM contains a comprehensive market description. This provides 
the information necessary for market participants to adapt their strategies - 
and possibly clients - to the market conditions. Compared to the implementa- 
tion a specification is much lighter and can be transferred more easily. Secondly, 
making the specification explicit and presentable in a formal way allows for sys- 
tematic analysis and comparison of market models that can also be automated. 
Software agents, for example, could automatically adapt their strategies based 
on such specifications. 

Spontaneous evolution profits from the MMM when one peer creates a new 
market. Again, a specific market model derived from the MMM is sure to con- 
tain a comprehensive description of this market. This is the origin for passing on 
this information as described above for the issue of spontaneous participation. 
To enable this, the MMM and a method for systematic refinement must be pro- 
vided for every market creator. 

The distinguished persistent entity missing in the ephemeral setting takes on 
the matching in traditional markets. The lack of this entity is made up for by 
passing on the market model, as the latter also contains the matching condi- 
tions. Their specification suffices to directly derive a matching implementation. 
This corresponds to the functionality of the central (matching) server in tradi- 
tional markets. In the ephemeral setting one or more peers have to substitute 
this service. 

The first case of a single peer providing the matching is most proximate 
with the traditional setting in mind. So, the one peer initiating a market could 
implement the matching conditions first, collect all offers in the corresponding 
imaginary container and match. As the initiator leaves, or at a time before that, 
he could pass on the responsibility for matching to another participant. 

5 http://www.w3.org/TR/owl-features/ 

6 http://www.w3.org/XML/ 
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The counterpart to the first approach is a completely decentralized match- 
ing where every participant matches all offers she sees - possibly only the ones 
interesting for herself. With several matching instances, the issue of multiple 
offers representing one intention must be resolved. One way is to technically en- 
sure authenticity, integrity and that offers cannot be duplicated. Then one can 
interpret every offer as unique and the associated participant could always be 
accounted for it. Since this is hardly possible in a decentralized setting with pos- 
sible freedom of implementation, we will look at a second way. The acceptance 
of an agreement can simply be kept explicit. Then, the participant associated 
with an offer implicitly confirms any offer when she accepts an agreement based 
on it. 

In a decentralized market it is not possible to immediately and reliably delete 
one or several offers that represent an intention. Yet, it is desirable to be able 
to express that an offer is not valid anymore. Therefore we propose adding an 
attribute construct to the intention class that describes the validity period of 
one intention, respectively every offer. 

7 Conclusion and Outlook 

The Minimal Market Model epitomizes the methodology of bottom-up market 
modeling, which offers a new perspective on markets. Furthermore, the MMM 
is an explicit, coherent specification of the market essence and presentable in 
a formal way. We elaborated on the economic challenges of ephemeral markets 
and proposed the MMM to tackle these challenges. 

The presented theoretical approach will be implemented in the project 
SESAM 7 and there be examined and tested in several applications. This will 
lead to refinement of this methodology and further research into its qualities 
and potentials. We will have to take a much closer look at the connection be- 
tween the theoretical level and the practical details. 

Moreover, we will elaborate on the systematic transition from the abstraction 
to concrete markets. We will, in particular, look at the integration of matching 
and allocation processes into market models. This effort includes the elabora- 
tion on information revelation. Making progress in this aspect would enhance the 
representation capabilities for auctions. Since the minimality in representation 
eliminates redundancy within the MMM, the information content is very dense. 
So, a wealth of contained information can be derived from the resulting market 
movies. This information extraction will also be subject to future research. 
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Abstract. Our approach to market modelling is based on analysis of the 
negotiation process execution tasks. We use this for extraction of the of- 
fer life cycle, which provides tasks to be modelled. Combined, these tasks 
constitute the process. In addition to the offer life cycle, the information 
flow in the market also needs to be modelled. For each task, we propose 
the use of components that can be concatenated to concrete market mod- 
els, whereby each component encapsulates one or more functional parts 
forming the complete process. We arrive at a structured approach to 
market modelling that is reduced in complexity because of the fragmen- 
tation of the modelling tasks. This approach is promising as it raises 
the modelling task to a high level of abstraction freeing the modeller 
from the implementation details. By way of example, we demonstrate 
how this approach can be employed to complete market models by using 
appropriate components. 



1 Introduction 

The progress of information technology has profoundly changed the structure of 
trading over the past two decades. A corollary of new forms of trading based 
on advancing computer technologies is a new organization of the exchange of 
goods and services in electronic markets. Electronic markets are commonly de- 
fined as inter-organizational information systems that allow buyers and vendors 
to exchange information about prices and product offerings [1]. They support 
electronic transaction processes, enabling multiple buyers and sellers to trade 
with technical aids, such as computers, to fulfil the needs of buyers, sellers, and 
other information carriers in respect of information dissemination and exchange. 

The setting of the market structure parameters determinates the market de- 
sign. Since the needs and demands of market participants require a market design 
that induces market efficiency and the setting of market structure parameters 
affects the market outcome, electronic markets have to be carefully designed. 
Central questions concerning market design are what parameters, rules, and cri- 
teria are necessary to compose a market, how such components can be defined, 
and how they can be composed to build a market. 

This paper presents a process-oriented approach to the design and imple- 
mentation of electronic markets. The approach is based on the offer life cycle, 
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defined by the stages each offer in electronic markets usually goes through. The 
benefit of process-orientation lies in facilitation of a higher level of abstraction in 
the design and implementation of electronic markets, which eases both of these 
tasks dramatically. 

Section 2 presents and discusses various researches in the context of auction 
and negotiation classification in respect of electronic markets. Section 3 presents 
a process-oriented approach to describe electronic markets that is needed to sim- 
plify and to clarify the design and implementation of electronic markets. Section 
4 shows that the process-oriented approach leads to component-based specifica- 
tion and composition of electronic markets. Section 5 examines a concrete ap- 
plication scenario and shows how the process-oriented approach presented here 
- together with the components and their composition - can be used to design 
electronic markets. Finally, a possible implementation for the concepts presented 
here is discussed and conclusions and presentation of the ambit of future work 
is presented in section 6. 



2 Related Work 

Since all auctions are negotiations, (but not vice versa, cf. [1]) we consider works 
from both fields of research in this section. McAfee and McMillan define an auc- 
tion as ”a market institution with an explicit set of rules determining resource 
allocation and prices on the basis of bids from the market participants.” Accord- 
ing to [2] , a microeconomic system consists of two distinct component elements: 
an environment and an institution, whereby the environment is defined as a ’’set 
of initial circumstances which can not be altered by the agents or the institutions 
within which they interact” [2]. 

An economic environment consists of economic agents (market participants), 
commodities (transaction object), and agent characteristics. The institution de- 
fines the language of the market, the communication rules for agents, and the 
condition under which the communication takes place [3]. The rules that define 
an institution can be subdivided into market microstructure, business struc- 
ture, and infrastructure. The market microstructure defines the trading rules, 
the business structure defines rules for the fee structure of the market, and the 
infrastructure defines rules given by the computerization of markets. The disjunc- 
tion between market microstructure and infrastructure is particularly relevant 
for electronic markets. Figure 1 illustrates the elements described above. 

The definitions outlined above describe microeconomic systems by giving 
a general survey of the elements that constitute a microeconomic system. Fur- 
ther considerations need to be made in order to clarify the various functions of 
these elements. Various schemata and ontologies for the classification of elec- 
tronic markets, electronic negotiations, and electronic auctions [4, 5] have been 
presented in scientific literature that aims to consider and describe them at an 
abstract level. For the most part, these schemata focus on a limited sub field of 
markets and do not provide a classification for markets in general. 
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Fig.l. Microeconomic system component elements based on [2] 



[6] presents a price-based general platform for electronic negotiation that 
supports multiple simultaneously running auctions. The authors mention that 
the ’’task of designing negotiation rules is that of designing auctions.” For this 
purpose, they define a classification of auctions in the form of a parameterisation 
of the auction design space focusing on the operational perspective of auctions. 
The authors categorize the parameters in three groups according to the basic 
activities common to all auctions: (1) receiving bids, (2) clearing, and (3) reveal- 
ing intermediate information. Each of these activities is further subdivided into 
message types defining the communication process between agents and the auc- 
tion server, and the handling of bids in it. According to this categorization, the 
authors have created a XML schema implementation of the parameterisation [7]. 

The agent communication language (ACL) defined by the Foundation of 
Intelligent Physical Agents (FIPA) provides a process-oriented view of the mod- 
elling of agent communication. ACL provides various message types explicitly 
intended to support negotiation. Nevertheless, it is inappropriate for defining 
the properties of negotiation protocols because ACL is intended to be used by 
agents during the negotiation. 

An approach for the definition of the agent communication in unified mod- 
elling language (UML) [8] - included into the FIPA’99 standard - is presented 
in [9]. The authors define an agent interaction protocol (AIP) that describes 
a communication pattern with an allowed sequence of messages between agents 
having different roles, constraints on the content of the messages, and a semantic 
that is consistent with the communicative acts (CAs) within a communication 
pattern. However, the granularity of the modelling is very fine and would lead 
to a modelling task that requires detailed knowledge about the communication 
process of the negotiation. Hence, AIP is inappropriate for market modelling at 
a higher abstract level. 
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Intention Phase Agreement Phase 




Fig. 2. Negotiation process execution tasks according to [5] 



[10] presents an ontology for automated negotiation. The task of this ontology 
is to ” provide the shared vocabulary permitting agents to negotiate in any kind of 
marketplace regardless of the negotiation mechanism that is used.” The authors 
see the advantages of their approach firstly in its flexibility and secondly in that 
it ’’provides a common terminology to reason in terms of negotiation protocols, 
their components, and the constraints regulating them” [10] . 

A further classification, ’’The Montreal Taxonomy” (MT) [5], is based on 
the media reference model (MRM) presented in [11]. The MRM identifies four 
phases of interaction: 1) knowledge; 2) intention; 3) agreement and 4) settlement 
(cf. [7]). 

MT states that ”an agreement process represents the complete agent inter- 
action in the intention and agreement phase for the coordination of one or more 
transactions” and thus it focuses on the intention phase and on the agreement 
phase of electronic transactions. The authors subdivide both of these phases 
into tasks related to the offer exchange in the electronic negotiation, whereby 
the final execution does not implicitly correspond to the given process model, 
and some tasks can be omitted. The intention phase has three subtasks: offer 
specification, offer submission, and offer analysis, whereby the subtasks of an 
agreement phase are: offer matching, offer allocation, and offer acceptance (cf. 
Figure 2). 

In summary, the classifications in [3] and [6] are based on similarities amongst 
negotiation protocols. [3] offers a ’snapshot’ description of microeconomic sys- 
tems or negotiation scenarios, whereby [6] also take into account operational 
perspectives of auctions - e.g. how they function. The classification given in [5] 
and the ontology introduced in [10] are more general approaches providing a ter- 
minology for electronic negotiations. 

It is of note that all the works referred to above consider the market as 
a system. However, in order to define and specify electronic markets we propose 
a change of paradigm in market modelling. Instead of focusing solely on the 
market as a system, we introduce an offer-oriented methodology for the market 
definition and description. The offer lifecycle stands in the foreground of the 
offer-oriented methodology and the modelling task is oriented to the phases 
in the offer lifecycle, from the offer specification till the offer execution. These 
phases are common to all negotiations, and particularly all auctions . The phases 
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define a process of offer handling in the market that forms a skeleton for the 
offer-oriented approach. 



3 A Process-Oriented Approach 

The preceding section discussed classifications for microeconomic systems and for 
electronic negotiations and proffers an offer-oriented approach of market mod- 
elling. This section presents a process-oriented approach to describe auction- 
based electronic markets. The intention of the approach presented here is the 
attainment of a high abstraction level of market modelling in order to free the 
market designer from implementation details. Our approach adapts to the nego- 
tiation process execution tasks (cf. Figure 2) and extracts functionalities needed 
to describe an electronic market. The objective of this section is the determina- 
tion of these functionalities. Note that we assume the transaction object type - 
which describes the objects of the negotiation - as pre-defined. Objects can be 
both material and immaterial goods that are transferred after an agreement in 
the negotiation is reached. In addition to the functionalities illustrated in Figure 
2, two further fields need to be modelled: information revelation and strategy 
(cf. [5, 6]). As these fields cannot be assigned to any certain functionality in the 
process oriented approach, they will be discussed briefly in section 3.2 (cf. [5]). 

In the following scenario, we consider a client-server based trading system 
where multiple clients are able to define and send offers (bids and asks) to a sin- 
gle electronic market system. Note that we do not focus on the implementation 
of such a system, but on the functionalities required for the process-oriented 
approach to describe electronic markets. The process-oriented approach is de- 
fined and structured as a reusable process. This means that the basic structure 
of the process is usable for similar transaction processes in electronic markets. 
In the abstraction level of modelling the basic transaction process is domain- 
independent: it is detached from the domain and from the transaction object as 
well as from the domain-specific behaviour of market participants. In addition, 
new auction types can be easily generated by specification of values of the basic 
activities within the transaction process. 

The diagram in Figure 3 illustrates the offer life cycle from the specification to 
the acceptance and shows both of the phases relevant to our approach (intention 
phase and agreement phase) from the negotiation process execution tasks. The 
client is responsible for the specification and submission of the offers (combined 
as ’’Client side”). The offer analysis, matching, allocation, and acceptance are 
executed in the server (combined as ’’Server side”). The starting point for the 
process-oriented approach is the life cycle of an offer, e.g. what happens with an 
offer from the moment of its definition in the trading client until its execution 
in the trading server. After an offer analysis the offer can be whether matched 
(Offer Matching) or not (Offer Matching). For example in continuous double 
auction the matching is executed directly an order inserted in a trading system. 
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Fig. 3. The offer life-cycle 



3.1 The Process 

Firstly, on the client side, the agent participating in the negotiation specifies 
the offer. The offer describes one single combination of values associated to the 
negotiation attributes. Note that each attribute is not necessarily used firsthand 
for the negotiation. Some attributes contain information necessary for the offer 
flow management. The offer specification indicates the constraints towards the 
transaction object. The process of the offer specification functionality does not 
need to be modelled independently of the negotiation. Irrespective of the various 
attributes, the process of the offer specification can be considered equal for all 
electronic markets. 

In the second step, the client submits the offer to the trading server. From 
a functional point of view, an agent requires a mechanism for the submission of 
an offer. Irrespective of the technical mode of communication, the submission 
mechanism can be considered equal in any electronic market system and thus 
need not be modelled separately for each single market. On the server side, the 
offer is first analysed, meaning that the offer is checked in respect of certain 
conditions or rules. For example, in an English auction, the value of the new 
offer has to be higher than the current best bid. Since each auction potentially 
varies in offer analysis rules, these must be explicitly modelled. The modelling 
provides a set of functions or rules to proof the offers invented into the current 
auction. Together, all these functions and rules build the functionality of offer 
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analysis. The number of various functions is limited. MT specifies only two rules: 
value and threshold. MT names three signs in both instances - for the value: 
ascending, descending, and undefined; for the threshold: low-cut, high-cut, and 
undefined. The rules given in the MT for the offer analysis can, for instance, be 
extended towards proofing whether the participant is allowed to submit an offer 
into the current market. 

In the next step, the offers are matched. The goal of matching is to find po- 
tential counterpart offers for the transaction execution. Note that the execution 
of the matching depends on the current auction type. In continuous auctions the 
matching is executed in each case after submission of an offer into the current 
auction, whereas in sealed bid auctions the matching is executed periodically in 
defined time intervals or triggered by events. Various distance functions can be 
used for matching. Mostly, the distance function in electronic markets is based 
on the price. Since the price is a numeric value, the distance function is a simple 
one but also auctions that are more complicated are imaginable. Since auctions 
are mechanisms for determining price and other terms of exchange [12], distance 
functions that use other parameters besides the price are used for the measure- 
ment of distance. For example, price can be combined with other properties 
like period of supply, or duration of the credit. Such multidimensional distance 
functions are used for the determination of quality rankings between offers and 
requests in electronic coordination scenarios, and are discussed in depth in [13]. 
For combinatorial auctions - which allow an expression of offers for combinations 
of goods and determine an allocation maximizing overall revenue - a detailed 
insight is delivered in [12]. 

The result of any price-based business negotiation process is a transaction, 
which specifies a certain transaction object at a certain price. The price de- 
termination for the transaction is done during the offer allocation. Thus, any 
implementation of an electronic market contains at least one mechanism for 
price-determination or price-generation. There are two conceivable ways to ac- 
complish the price-determination: (1) sealed-bid or (2) out-cry. In the first case 
a number of bids and requests are collected. The price is determined automat- 
ically according to predefined rules, e.g. the maximisation of total transaction 
volume. Examples for this kind of price-determination are the Vickrey-auction 
and the call market. In the second case, the price determination process is con- 
tinuously executed to compute the ’’best” available price at any moment for 
the transaction. The ’’best price” is the lowest possible price for the buyers 
and the highest possible price for the sellers. Auction forms such as the English 
auction, Dutch auction, and continuous double auction have an out-cry price- 
determination mechanism. Like the execution of the matching, the execution of 
the offer allocation also depends on the current auction form. For example, in the 
standard English auction and Dutch auctions the allocation is done only once, 
namely at the point when the auction ends. Thus, the offer allocation must also 
be modelled explicitly. 
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3.2 The Process Independent Criteria 

As mentioned above, the information revelation and the strategy must also be 
modelled for electronic markets. Since both of these aspects are not bound with 
any specific state in the order life cycle and thus not bound with any phase in 
the process, they need to be modelled independently. 

Information Revelation The rules for information revelation define the 
amount, kind, and timing of information used for the communication during 
a negotiation, whereby sealed bid auctions do not reveal any information per 
definition. In [6] and [14] Wurman et al. identify four kinds of information that 
can be supplied to the participating auction agents: order book, price quotes, 
transaction history, and schedule information. Information supply can easily be 
defined by auction parameters according to these. An extensive presentation of 
criteria for the information revelation is given in the MT. Since the MT proposes 
a taxonomy for electronic negotiation, some criteria presented in it overlap with 
those discussed in [6] and [14]. 

An order book is used to list current bids [14]. The authors state: ’’Many 
online auction sites have a policy of revealing all of the bids.” Beyond this, they 
note that auctions can reveal more differentiated information. The revelation of 
the information can be differentiated in various ways. In addition to those criteria 
given in the MT, we identify two further criteria of information revelation: the 
breadth and the depth. The breadth declares attributes of bids visible from the 
order book for the agents and the depth specifies the number of the bids visible 
from the order book. 

The Strategy The strategy rules define the fees for the services that the 
market platform supplies to the participants. Electronic markets are exposed 
to competition among the customers. Accordingly, market place operators need 
to offer better and more differentiated services to the customers. Thus, offered 
services vary in fees customers need to pay for their usage. Therefore, fees need 
to be modelled. For example, the order book breadth and the order book depth 
can be concatenated with fees. A more detailed discussion about fees is available 
in [15]. 

4 Components 

Some basic concepts for the implementation of the process-oriented approach 
with components are discussed in this section. In the software engineering do- 
main components are defined as ”a physical and replaceable part of a system 
that conforms to and provides the realization of a set of interfaces... [component] 
typically represents the physical packaging of otherwise logical elements, such as 
classes, interfaces, and collaborations” [8]. This general definition focuses both 
the software conception and its implementation. The component definition given 
below considers both of these aspects, whereby the conceptual level of the market 
modelling is in the foreground. 
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4.1 Component Definitions 

Firstly, we consider components as a set of rules R = {Ri, R2, ■ • ■ , Rk} with Ri, 
i £ {l,...,fc}, k mutual independent rules, and a set of algorithms A = 
{Ai,A2, . . . , Ai} with Aj, j £ {1 , . . . , l}, l mutual independent algorithms. We 
define a component C as a set of rules R and a set of algorithms A that is 
C = {R, A}. For instance an auction with one seller, multiple buyers, and win- 
ner determination according to lowest bid contains following components: Ci = 
{Participation(two-sided)}, C2 = {Agents(n bidders:l auctioneer)}, and C 5 = 
Provision (offer-dependent ) . 

For the concatenation of these components to new components and finally 
to new market structures [16] defines a logic composition operation o for two or 
more components. For example, the components C\ and C2 can be used to build 
a new component C = C\ 0C2. In this case, C\ and C2 are subcomponents of C. 

The recursive definition of components and their composition lead directly 
to a definition for a component based market structure: M = C\ o C2 o . . . o C n = 
{Ri, Ai}o{R 2l A 2 }o. . . o{R n , A n }. This definition enables us to build up a market 
structure from components using the composition. 

For the structured market modelling it is useful to adjust the component 
definition such that it takes into account the process-oriented approach. Note 
that our component definition differentiates from the definition in [8] (p. 343) 
in that it considers not solely the ’’physical packaging of otherwise logical ele- 
ments, such as classes, interfaces, and collaborations” but also their parameter- 
isation. For example, the rules to control the admission of market participants 
into one electronic market can be defined by agents and groups of agents whom 
the admission is prohibited or allowed. In the example above we defined an 
auction with one seller and multiple buyers with following components: C\ = 
Participation(two-sided), C2 = Agents(n bidders:!, auctioneer). A further com- 
ponent C3 = (Admission([list of agents allowed to admit into the market])) leads 
together with C\ and C2 to an two-sided auction with 1 auctioneer and n bidders, 
whereby only bidders given in the component C3 are allowed to take part. 

4.2 Component Classes 

Components are based on rules and algorithms that customarily govern the pro- 
cess in a market. The offer life cycle defines the main component in the process- 
oriented approach. As mentioned above, the current auction type determines the 
order life cycle. [6] provides a classification of traditional auction types. These 
are illustrated in Figure 4. 

Each auction type defines a basic structure of communication with agents. 
Hence, these types can be used as a skeleton for the definition of the offer life 
cycle and consequently for the definition of the communication components. 
Each auction type follows the negotiation process execution tasks (cf. Figure 2). 
Consequently, an order life cycle according to Figure 3 exists for each auction 
type. Thus, components for the communication mechanisms can easily be defined 
for further auction types. 
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Fig. 4 . A classification of classic auction types [6] 



Further components can be identified and deduced from phases of the order 
life cycle (cf. Figure 3). For each single phase, characteristic components can be 
defined according to the relevant tasks that need to be executed. For example, 
corresponding components are needed for the offer matching or for the offer 
analysis. 

As mentioned above, process independent criteria cannot be modelled based 
on order life cycle. Thus, components to implement the information revelation 
and fees have to be provided separately. 

5 Composition of Components 

This section demonstrates how concrete market models can be assembled using 
components and the process-oriented approach presented in this work. Consider 
therefore a Reverse 1 st Price Sealed Auction (Ci) for eProcurement where one 
buyer (C 2 ) wants to buy a computer system and multiple sellers (C 3 ) offer in 
a one round bidding (C 4 ) auction. The winner will be determined according to 
lowest bid (C 5 ). The price and the bidder name of the five best offers will be 
published at the end of the auction (Cg). All bids must be submitted online, 
no later than 5:00 p.m., Friday November 14, 2003 (C 7 ). Bids received after the 
designated date and time will not be considered. Bidding will commence at 10:00 
a.m., Tuesday December 2 2003 (C$). If there are two or more identical high bids, 
the apparent high bidder will be determined by the earliest date-received stamp 
(Cg). Withdrawal of offers is not allowed (Cio)- 

5.1 Modelling of the Process 

As above mentioned the auction form used is a Reverse 1st Price Sealed Auc- 
tion. In the process-oriented approach, first step to do is the selection of the 
component for the communication. Note that the definition of the communica- 
tion component C = C\ o C 2 o C 3 o C 4 determinates the order life cycle. Having in 
mind the order life cycle presented in Figure 3 and assuming that the definition 
of the transaction object is already done (a computer system), the relevant part 
of the order life cycle starts with the offer analysis. 



A Process-Oriented Approach Towards Structured Market Modelling 



111 



Analysis: For this auction there are no limits for the participation or no rules 
for the value and threshold given. The only limitation given is that all bids must 
be submitted online, no later than 5:00 p.m., Friday November 14, 2003 and bids 
received after the designated date and time will not be considered (CV). 

Matching: The bids will be opened beginning at 10:00 a.m., Tuesday, De- 

cember 2, 2003 means that the matching will be started at that time (Cg). For 
the matching relevant attribute is the price (C5). From there, two components 
need to be created: one to define at what time the matching will start (Cg) and 
another to implement the matching according to the lowest bid (C5). Note that 
the matching is here used to sort the bids in the current auction according to 
the price and date-received, because by identical high bids, the apparent high 
bidder will be determined by the earliest date-received stamp. 

Allocation: All bids will be opened beginning at 10:00 a.m., Tuesday, December 
2, 2003. This means that the allocation starts at that time and can be defined 
with the component (Cg). The winner is the submitter of the offer with the 
lowest bid (C5). For two or more identical bids, the apparent high bidder will 
be determinated by the earliest date-received stamp (Cg). For the allocation, 
two components are needed: one to control the starting of the allocation and the 
second one to determine the winner according to the lowest bid. 

Acceptance: Because the withdrawal of the offers is not allowed (CiO), the 
last component to create permits the withdrawal of submitted offers. Composing 
these components together leads to a component based market structure: M = 
C0C50C70CS0CQ0C10. New component based market structures can be reached 
just by changing one of the components or by insertion/deletion of components 
into/from the existing market structures. 

5.2 Modelling of the Information Flow 

In addition to the process modelling, the process independent criteria (cf. Sec- 
tion 3.2) also need to be modelled. According to the rules for the auction outlined 
above, the bidder names of the five best offers will be published at the end of 
the auction (Cg). This means that from the first five bids in the order book the 
bidder name and the offered price will be published at the end of the auction 
(therewith it is obvious that the information flow is a process independent cri- 
teria: the timing of the information publishing can be chosen free irrespective of 
the offer life cycle). Consequently, three components need to be defined: firstly, 
component C a that defines the breadth declares attributes visible in the auc- 
tion for the agents (here the name and the price), secondly the component Cb 
that defines the depth to specify the number of the visible bids (here five), and 
thirdly the component C c that defines the timing for the information revelation. 
This means that the component Cg is a composition of the components C a , Cb , 
and C c . 
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6 Conclusions and Future Work 

A rise in the level of interest in computer supported electronic markets is charac- 
teristic of the past few years. Theoretical foundations for the design and imple- 
mentation of such systems are given among other things by systematic analysis of 
the nature of microeconomic systems, negotiations, and auctions. In this paper, 
we first presented an overview of research in these fields and ascertained that 
(electronic) markets and (electronic) negotiations are analysed as systems. Hav- 
ing identified the difficulties for market design, we proposed a process-oriented 
approach towards structured market modelling. The process-orientation that we 
presented is based on the offer life cycle, from which we deduced a common 
process for offers in any negotiation system. This process consists of six phases: 
specification, submission of the offer (processed on the ’’Client side”) and offer 
analysis, matching, allocation, and acceptance (processed on the ’’Server side”). 
We stated that each of these phases contains specific functions that need to be 
modelled. In addition to the modelling of the offer life cycle, we showed the need 
for the separate modelling of information revelation and strategy because both 
cannot be assigned to any certain functionality in the order life cycle. 

Subsequent to the definition of components and their composition, we demon- 
strated using a concrete example how the process-oriented approach based on 
the order life cycle could be effectively used to define a market structure. 

A further aspect, not featured in this paper, but which we are working on, is 
the market modelling language MML - a semi-formal component-based language 
for the modelling and specification of electronic markets. The MML is based on 
the process-oriented approach presented in this work and on the parameterisa- 
tion of that process. The MML contains components for the specification of the 
offer life cycle, the information revelation and the strategy, allowing the market 
designer easily to design new market structures. We consider that this frees the 
market designer from implementation details and that a higher level of mod- 
elling abstraction leads to better understanding of electronic markets and the 
mechanisms behind them. 
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Abstract. We consider the formal specification and validation of sys- 
tems where probabilistic information is not given by means of fixed values 
but as sets of probabilities. These sets will be intervals contained in (0, 1] 
indicating the possible value of the real probability. In order to specify 
this kind of systems we will introduce a suitable extension of the notion 
of finite state machine. Essentially, choices between transitions outgo- 
ing from a state and having the same input action are probabilistically 
resolved. We will also present some implementation relations to assess 
the conformance of an implementation to a specification. The first im- 
plementation relation will clearly present the probabilistic constraints of 
the specification, but it will be unfeasible from the practical point of 
view. The other relations will overcome the problems of the first one by 
introducing a notion of conformance up to a given level of confidence. 
These relations will assess the validity of an implementation with re- 
spect to a specification by considering a finite sample of executions of 
the implementation and comparing it with the probabilistic constraints 
imposed by the specification. 



1 Introduction 

During the last years we have seen an evolution in the kind of systems that formal 
methods are dealing with. In the beginning the main focus was on functional 
properties. The next step was to consider quantitative information such as the 
time underlying the performance of the system or the probabilities resolving the 
non-deterministic choices to be taken. Following this line, plenty of frameworks 
considering time and/or probabilistic aspects have been proposed (e.g. [1, 2, 3, 
4, 5, 6, 7, 8, 9, 10]). 

In this paper we concentrate on the formal specification and validation of 
a novel notion of probabilistic systems. One of the main criticisms about for- 
mal models including probabilistic information is the inability, in general, to 
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accurately determine the actual values of the involved probabilities. The usual 
inclusion of probabilities is given by (using a process algebraic notation) pro- 
cesses such as P = a + 1 b. In this case, P may be thought as expressing that if 
the choice between a and b must be resolved then a has probability i of being 
chosen while b has probability |. However, there are situations where it is rather 
difficult to be so precise when specifying a probability. A very good example is 
the specification of faulty channels (e.g. the classical ABP [ 1]). Usually, these 
protocols contain information such as “the probability of losing the message is 
equal to 0.05.” However, two questions may be immediately raised. First, why 
would one like to specify the exact probability of losing a message? Second, how 
can the specifier be sure that this is in fact the probability? In other words, 
to know the exact value seems as a very strong requirement. It would be more 
appropriate to say “the probability of losing the message is smaller that 0.05.” 
Such a statement can be interpreted as: “we know that the probability is low but 
we do not know the exact value.” Moreover, our approach, that we call symbolic 
probabilities, allows us to use successive refinements. For example, let us suppose 
that after experimentation with the system we have detected that some messages 
are lost (so that we can discard that the probability of losing a message is equal 
to zero) but not many messages were lost. By using the appropriate statistics 
machinery (mainly hypothesis contrasts and Tchebyshev inequality) we may in- 
dicate information such as “with probability 0.95 the real probability of losing 
the message belongs to the interval [0.01,0.03].” 

In this paper we present a formalism to specify symbolic-probabilistic sys- 
tems. We will consider a suitable extension of finite state machines where proba- 
bilistic information is included in the appropriate places. Intuitively, transitions 
in finite state machines indicate that if the machine is in a state s and receives 
an input i then it will produce an output o and it will change its state to s'. An 

appropriate notation for such a transition could be s — - — * s' . If we consider 

a probabilistic extension of finite state machines, transitions as s — - — > p s' in- 
dicate that the probability with which state s performs the output o after the 
input i is received and reaches state s' belongs to the range given by the expres- 
sion p. For instance, p may be the interval [j, |] while the real probability is in 
fact 0.53. 

An important issue when dealing with probabilities consists in fixing how 
different actions/transitions are related according to the probabilistic informa- 
tion. In [5] a taxonomy, that has become classical, is given. In this paper we 
consider a variant of the reactive interpretation of probabilities since it is the 
most suitable for our framework. Intuitively, a reactive interpretation imposes 
a probabilistic relation among transitions labeled by the same action, but with- 
out quantifying how choices between different actions is resolved. In our case, 
our probabilistic finite state machines will be able to express probabilistic rela- 
tions between transitions outgoing from a given state and having the same input 
action (while the output action may vary). In the following example we illustrate 
this notion of probabilities (the formal definition of our notation will be given 
in the next section). 
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Example 1. Let us consider that the unique transitions from a state s are 

ii/oi ix/o'i ii/o 3 

t\ — S > p 1 Si 62 — & * p 2 ^2 ^3 — $ ^£>3 ^2 

*2/01 *2/03 

64 — S > p 4 S3 £5 — S > p 5 Si 

If the environment offers the input action i\ then the choice between ti, £ 2 , 
and £3 will be resolved according to some probabilities fulfilling the conditions p \ , 
P 2 , and J 53 . All we know about these values is that they fulfill the imposed 
restrictions, that they are non-negative, and that the sum of them equals 1 . 
Something similar happens for the transitions 1 4 and 1 5 . However, there does 
not exist any probabilistic relation between transitions labeled with different 
input actions (e.g. t\ and t. 4 ). □ 

In addition to the definition of our formalism, we have also developed appro- 
priate implementation relations to try and determine whether an implementation 
conforms to the behavior indicated by the corresponding specification. We have 
to take into account that, in general, we will not be able to see the probabil- 
ities that the implementation has assigned to each of the choices. Thus, even 
though implementations will behave according to fixed probabilities, in contrast 
with specifications, the problem is that we will not be able to read their values. 
Following the approach presented in [12], in order to compute the probabilities 
associated with each choice of the implementation we will analyze some sam- 
ples collected from the implementation. By comparing them with the symbolic 
probabilities of the specification we will be able to assess the validity of the im- 
plementation. This comparison will be performed by using hypothesis contrasts. 
These contrasts allow to (probabilistically) decide whether an observed sample 
follows the pattern given by a random variable. 

The rest of the paper is organized as follows. In Section 2 we present our 
probabilistic finite state machines model. In Section 3 we introduce some basic 
statistical concepts that are (abstractly) used along the paper. In Section 4 
we give our first implementation relation and show that, regardless its elegant 
definition, it is not adequate from the practical point of view. In Section 5 
we present new implementation relations that can be checked in practice. The 
underlying idea is that these relations perform a hypothesis contrast to assess 
whether the observed behavior corresponds to the probabilistic behavior defined 
in the specification up to a certain confidence. Finally, in Section 6 we present 
our conclusions and some lines for future work. 

2 Probabilistic Finite State Machines 

In this section we introduce our notion of probabilistic finite state machines. As 
we have previously commented, probabilistic information will not be given by 
using fixed values of probabilities but by introducing certain constraints on the 
considered probabilities. By taking into account the inherent nature of proba- 
bilies we will consider that these constraints are given by intervals contained in 
(0,1] C R. 
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Definition 1 . We define the set of symbolic probabilities , denoted by simbP, as 
the following set of intervals 



simbP = 



j$pi,p 2 & 



pi,p 2 G [0,1] A pi < p 2 A $ G { (, [ } A & G { ),] } A 
0 ^ $pi,p 2 & A $pi,p 2 & ^ 0 



If we have a symbolic probability as \p,p), with 0 < p < 1, we simply write p. 

Let p 1 , ... ,p n G simbP be symbolic probabilities such that for any 1 < i < n 
we have p t = $iPi, qi&Ci, with $j G { (, [ } and &;* G { ), ] }. We define the product 
of p 1 , ... ,p n , denoted by \\p (respectively the addition of p 1: ... ,p n , denoted 
by Pi) as the symbolic probability & Y[pi^ II (respectively & ^2 Pi, <!$)■ 
The limits of the interval are defined in both cases as: 



f ( if 31 < i < n : &,; = ( 
( [ otherwise 



( ) if 31 < i < n : $* =) 
1 ] otherwise 



□ 



The previous definition expresses that a symbolic probability p is a non- 
empty (open or closed) interval contained in (0, 1]. In particular, we will not allow 
transitions with probability 0 because this value would complicate (even more) 
our model since we would have to deal with priorities. 1 We have also defined how 
to multiply and add symbolic probabilities. The maximal (resp. minimal) bound 
of the resulting interval is obtained by operating over the respective maximal 
(resp. minimal) bounds of the intervals considered. Next, we introduce our notion 
of probabilistic finite state machine. In the following we consider that | A| denotes 
the cardinality of the set X. 

Definition 2. A Probabilistic Finite State Machine , in short PFSM, is a tuple 
M = ( S , I, O, S , so) where S is the set of states, I and O denote the sets of 
input and output actions, respectively, SCSxIxOx simbP x S is the set of 
transitions, and so is the initial state. Each transition belonging to S is a tuple 
(s,i,o,p,s') where s,s' G S are the initial and final states, i G I is an input 
action, o G O is an output action, and p £ simbP is the symbolic probability 
associated with the transition. We will usually denote transitions as (s, i. o^p, s 1 ) 

by s — - — > p s' . Besides, we consider that for any s G S, i G I, and the set 

i jo i jo 

ot s ,i = {s *p s' | 3 o G 0,p G simbP, s' G S : s s' G 5} the following 

two conditions hold: 

— If | a s y | > 1 then for any s — - — >p s' G a s ^ we have that 1 ^ p. 

- 1 G |3oGO,s'g5:s %l ° > v s' G a Sti }. 



□ 

1 The interested reader can check [13] where different approaches for introducing pri- 
orities are reviewed. 
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Intuitively, a transition s — - — >p s' indicates that if the machine is in state s 
and receives the input i then, with a probability belonging to the interval p, 
the machine emits the output o and evolves into s' . As we pointed out in the 
introduction of the paper, this interpretation of the probabilistic information 
follows the reactive model as described in [5]. Let us comment the restrictions 
introduced at the end of the previous definition. The first constraint indicates 
that a symbolic probability such as p = $p, 1 ] can appear in a transition like 

s — - — » p s' £ S only if it is the unique transition for s and i. Let us note 

. _ . • • i/o . i/o' .. ci 

that it there would exist two transitions s * p s , s » p> s G 0 and 

the probability of one of them (say p) included 1 , then the (real) probability 
associated to the other transition (p') could be 0, which is forbidden. Regarding 
the second condition, let us note that the real probabilities for each state s £ S 
and for each input i £ I should add 1. This is only possible if 1 is within the 
lower and upper bounds of the associated symbolic probabilities. 

Next we define some additional conditions that we will sometimes impose on 
our probabilistic finite state machines. 

Definition 3. Let M = (S, I, O, 6 , so) be a PFSM. We say that M is input- 
enabled, if for any state s £ S and input i £ I there exist s' £ S, o £ O, and 
p £ simbP such that (s, i, o,p, s') £ S. 

We say that M is deterministically observable if for any s £ S, i £ I, and 
o £ O there do not exist two different transitions (s, i, o,Pi, si), (s, i, o,p 2 , S 2 ) £ 5. 

□ 

First, let us remark that the previous concepts are independent of the prob- 
abilistic information appearing in the state machines. Regarding the notion of 
deterministically observable, it is worth to point out that it is different from the 
more restricted notion of deterministic finite state machine. In particular, we 
allow transitions from the same state labeled by the same input action, as far as 
the outputs are different. 

Example 2. Let us consider the (probabilistic) finite state machines depicted in 
Figure 1. For the sake of clarity, we have not included probabilistic information 
in the graphs. Let us consider M 3 = ({1, 2, 3}, {*i, * 2 }, { 01 , 02 , 03 }, 5, 1). Next 
we define the set of transitions 6. For the first state, we have the transitions 
(1, i\, 01 , 1, 2), (1, i 2 , oi,p 1: 1), and (1, i 2 , o 2 ,p 2 , 3)- Let us suppose that p x = (0, 5 ] 
and p 2 = [g , 1 ), and let us remind that we denote the interval [ 1 , 1 ] simply by 1 . 
We also know that the real probabilities associated with the last two transitions, 
say pi and p 2 , are such that pi + P 2 — 1. A similar assignment of symbolic 
probabilities can be done to the rest of transitions appearing in the graph. 

Regarding the notions of input-enabling and deterministically observable, we 
have that Mi fulfills the first of the properties but not the second one (there are 
two transitions outgoing from the state 3 labeled by ii/o 3 ). The first property 
does not hold in M 2 (there is no outgoing transition labeled by *2 from the 
state 2) while the second one does. Finally, M 3 holds both properties. □ 
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n/03 



Fig. 1. Examples of PFSM 

As usually, we need to consider not only single evolutions of a PFSM but 
also sequences of transitions. Thus, we introduce the notion of (probabilistic) 
trace. We will associate probabilities to traces. The probability of a trace will be 
obtained by multiplying the probabilities of all transitions involved in the trace. 

Definition 4. Let M = ( S , I, O, 5 , so) be a PFSM. We write the generalized tran- 

(h/oi,...,i n /o n ) ' _ _ 

sition s V p s if there exist si, . . . , s„_i £ S,p 1 , . . . ,p n £ simbP 

such that s — 1 - - -~> p 1 si — 2 - ■ 2 > p 2 S2 • • • s n _ 1 — n - ■ " > p n s' and p = np?:- 

We say that p = (ii/01, . . . , i n /o n ) is a non-probabilistic trace, or simply 

a trace, of M if there exist s' £ S and p £ simbP such that so ==>p s'. 

Let p = (ii/01, . . . , i n / o n ) and p £ simbP. We say that p = (p,p) is a proba- 
bilistic trace of M if there exists s' £ S such that So ==>p s'. 

We denote by Traces(A/) and pTraces(AZ) the sets of non-probabilistic and 
probabilistic traces of M, respectively. □ 

3 Statistical Concepts 

In this section we introduce some statistical notions that will be used in our 
framework and a procedure to perform hypothesis contrasts. In the following 
definition we call event to any reaction we can detect from a system. For any 
set of events, a sample denotes the number of times we have detected each event 
along a set of observations. Besides, we associate a random variable with each 
set of events. Its purpose is to provide the theoretical ( a priori) probability of 
each event belonging to the set. In our framework, these random variables will be 
inferred from the PFSMs denoting the (ideal) probabilistic behavior of systems, 
while the samples will be collected by interacting with the implementation to be 
validated. We will consider a variant of random variable allowing to deal with 
symbolic probabilities. Besides, we provide a function that returns the confidence 
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we have that a sample of events has been produced according to a given random 
variable. This function encapsulates the contrast hypothesis in our framework. 

Definition 5. Let A = {ai, . . . , a„} be a set of events. A sample of A is a set 
J = {(ai, mi), . . . , (a n , m n )} where for any 1 < i < n we have that m,; represents 
the number of times that we have observed the event a,;. 

Let £ : A — ■> simbP be a function such that 1 € this case we 

say that £ is a symbolic random variable for the set of events A. We denote the 
set of symbolic random variables for the set of events A by TZV(A). We denote 
the set of symbolic random variables for any set of events by 1ZV. 

Given the symbolic random variable £ and the sample J we denote the con- 
fidence of £ on J by y(£, J). □ 

We assume that 7(5, J) takes values in the interval [0, 1]. Intuitively, bigger 
values of y(£, J) indicate that the sample J is more likely to be produced by the 
symbolic random variable £. In the next definition we particularize the previous 
notions in the context of our framework. Basically, we give a sequence of inputs 
and consider the sequence of outputs that the system can return. Hence, the 
set of events are those sequences of outputs that could be produced in response. 
The random variable denoting the theoretical probability of each event is com- 
puted by considering the symbolic probability of the corresponding trace in the 
specification. 

Definition 6. Let M = ( S , /, O, S, so) be a PFSM. Let n = (ii,...,in) be a se- 
quence of inputs. The set of trace events associated to M with respect to n, 
denoted by TraceEvents(Af, 7r), is defined as 

TraceEvents(M, 7r) = {(01, . . . , o n ) | (*i/oi, . . . , i n /o n ) £ Traces(M) } 

The symbolic random variable associated to the previous events, denoted by 
is defined such that for any (oi,...,o„) £ TraceEvents(M, n) we have 
^(oi,...,o„) = p, where ((ii/01, . . . , i n /o n ),p) £ pTraces(M). □ 

Now we introduce one of the standard ways to measure the confidence that 
a random variable has on a sample. In order to do so we will present a method- 
ology to perform hypothesis contrasts. Intuitively, a sample will be rejected if the 
probability of observing that sample from a given random variable is low. In 
practice, we will check whether the probability to observe a discrepancy lower 
than or equal to the one that we have detected is low enough. We will present 
Pearsons % 2 contrast. This contrast can be applied both to continuous and dis- 
crete random variables. The mechanism is the following. Once we have collected 
a sample of size n we perform the following steps: 

— We split the sample into k classes covering all the possible range of values. 
We denote by Oi the observed frequency in class i (i.e. the number of elements 
belonging to the class i). 

— We calculate, according to the proposed random variable, the probability pi 
of each class i. We denote by Ei the expected frequency of class i, that is, = 

npi. 
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— We calculate the discrepancy between observed and expected frequencies 

as X 2 = 1 ■ When the model is correct, this discrepancy is 

approximately distributed as a random variable % 2 . 

— The number of freedom degrees of x 2 is k — 1. 

— We will accept that the sample follows the proposed random variable if the 
probability to obtain a discrepancy greater than or equal to the detected 
discrepancy is high enough, that is, if X 2 < y^{k— 1) for some a high enough. 
Actually, as such margin to accept the sample decreases as a increases, we 
can obtain a measure of the validity of the sample as max{a|X 2 < x^(k— 1)}. 

According to the previous steps, we can now present an operative definition 
of the function 7 which has been presented before in Definition 5. Since we will 
use hypothesis contrasts to compare samples with symbolic random variables but 
the previous procedure refers to standard random variables, we must be carefull 
when applying the previous ideas in our framework. Let us note that symbolic 
random variables encapsulate a set of standard random variables (this set is 
in general infinite). For instance, let us consider the set of events A = { a,b } 
and the symbolic random variable £ : A — » simbP with £(a) = £(&) = (t, d). 
Then, a possible standard random variable fitting into £ is £' : A — > (0, 1] 
with £'(a) = 5 and £'(6) = |. Another possibility is £" : A — > (0, 1] with 
£"(a) = £"(6) = 2 • Since £ embraces both possibilities, assessing the confidence 
of ^ on a sample should consider both of them. Actually, we will consider that 
the sample is adequate for £ if it would be so for some standard random variable 
fitting into £. More generally, an instance of a symbolic random variable is a 
(standard) random variable where each probability fits into the margins of the 
symbolic random variable for the corresponding class. Besides, the addition of 
the probabilities must be equal to 1. In order to compute the confidence of 
a symbolic random variable on a sample we consider the instance of it that 
returns the highest confidence on that sample. 

Definition 7. Let A = {ai, . . . , a*,} be a set of events, £ : A — > simbP be a sym- 
bolic random variable, £' : A — *■ (0, 1] be a random variable, and J be a sample 
of A. We say that the random variable £' is an instantiation of £, denoted by 
Instance(£', £), if for any a £ A we have £'(a) € £(a) and )C 0 .e.4 C( a ) = L 
For any random variable £' : A — > (0, 1] let A 2 denote the discrepancy level 
of J on £' calculated as explained above by splitting the sampling space into 
the set of events A. Let £ : A — > simbP denote a symbolic random variable. We 
define the confidence of £ on J, denoted by y(£, J), as follows: 

7(£, J) = max 

□ 




4 Probabilistic Implementation Relation 

In this section we introduce our first implementation relation. We will consider 
that both specifications and implementations are given by deterministically ob- 
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servable PFSMs. Moreover, we will assume that PFSMs representing implementa- 
tions are input-enabled. We assume that implementations are black-boxes. Thus, 
no information can be known about their internal behavior/structure. In addi- 
tion, let us remark that the symbolic probabilities appearing in implementations 
follow the pattern \p,p] (or simply p ), for some p £ (0, 1]. That is, they are in- 
deed fixed probabilities. While specifications are abstract entities where symbolic 
probabilities allow us to represent different scenarios (one for each probability 
within the intervals) in a compact fashion, implementations represent concrete 
machines. Hence, even though observations will not give us the actual probabil- 
ity associated to a transition in an implementation, we may rely on the fact that 
the probability is indeed fixed. 

Regarding the performance of actions, our implementation relations follow 
the classical pattern of formal conformance relations defined in systems distin- 
guishing between inputs and outputs (see e.g. [14, 15]). That is, an implementa- 
tion X conforms to a specification S if for any possible evolution of S the outputs 
that the implementation may perform after a given input are a subset of those 
for the specification. Besides, this relation will require that the probability of any 
trace of the implementation is within the corresponding (symbolic) probability 
of the specification for this trace. 

Definition 8. Let S and X be PFSMs. We say that X non-probabilistically con- 
forms to S, denoted by X conf <S, if for any p = (ii/oi, . . . , i n /o„) £ Traces(<S), 
with n > 1, we have 

p' = (ii/oi, . . . ,i n -i/o n -i,i n /o' n ) £ Traces(I) implies p' £ Traces(S) 

We say that X probabilistically conforms to S , denoted by X conf <S, if X conf S 
and for each p = (p,p) £ pTraces(I) we have 

p £ Traces(iS) implies (p,p) £ pTraces(iS) for some p with p £p. 



□ 

Intuitively, the idea underlying the definition of the non-probabilistic confor- 
mance relation conf is that the implementation X does not invent anything for 
those inputs that are specified in the specification (this notion has been previ- 
ously used, with some variants, in [16, 12]). This condition is also required in the 
probabilistic case: We check probabilistic traces only if they can be performed 
by the specification. 

The problem underlying this implementation relation is that we have no ac- 
cess to the probabilities governing the transitions of the implementations. So, we 
are not able to check whether a given implementation probabilistically conforms 
to a specification. However, we may get approximations of the probabilities con- 
trolling the behavior of the implementation by collecting samples of its execution 
and computing the empirical ratio associated with the different decision points 
of the implementation. 
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5 Implementation Relations Based on Samples 

In the previous section we presented an implementation relation that clearly ex- 
pressed the probabilistic constraints an implementation must fulfill to conform 
to a specification. Unfortunately, this notion is useful only from a theoretical 
point of view since the correctness of the probabilistic behavior of an implemen- 
tation with respect to a specification cannot be checked by using a finite number 
of observations. In this section we introduce new implementation relations that 
take into account the practical limitations to collect probabilistic information 
from a given implementation. We will present new versions of the relation de- 
fined in Section 4. These new relations allow us to claim the accurateness of 
the probabilistic behavior of an implementation with respect to a specification 
up to a given confidence level. Given a set of execution samples, obtained from 
the implementation, we will apply a hypothesis contrast to check whether the 
probabilistic choices taken by the implementation follow the patterns given by 
the specification. 

In order to introduce our new relations, we need some notions to deal with 
samples collected from an implementation. The next definition presents some 
auxiliar predicates that we will use during the rest of the section. While the 
first two notions are easy to understand, the last one needs some additional 
explanation. Given a trace p and a set H of pairs (trace, natural number), 
IPref i x(H, p) is another set of pairs including all traces such that its sequence of 
input actions matches that of p. The number attached to each trace corresponds 
with the number of traces belonging to H beginning with that trace. For in- 
stance, let us consider the set of pairs H = {((*i/oi, *2/01), 1), ((U/02, h/02), 2), 
({ii/ 02,12/01), 3), ((*2/01, *2/02), 4)} and let us apply the function to the trace 
(*i/oi)- Then, the resulting set is H' = {((q/01), 1), ((U/02), 5)}. Let us remark 
that we discard the output of the trace considered as parameter. For instance, 
in the previous example we considered the trace (q/01) but the resulting set 
contained information for both ( i\/o \ ) and ( U/02 )■ Given a sample of execu- 
tions from an implementation, we will use this function to calculate the number 
of times that the implementation has performed each sequence of outputs in 
response to some sequence of inputs. Let us note that if we observe that the 
sequence of outputs (01, . . . , o„) has been produced in response to the sequence 
of inputs (ii,..., i n ) then, for any j < n, we know that the sequence of outputs 
(01, . . . , Oj) has been produced in response to (q, . . . ,ij). Hence, the observation 
of a trace is useful to compute the number of instances of any prefix of it. 

Definition 9. Let er = (iq, . . . , u n ) and o' = (u\, ... , u' m ) be two sequences. 
We say that o is a prefix of o ' , denoted by Pref ix(cr, o'), if n < to and for any 
1 < i < n we have Ui = it'. 

Let p = (ii/oi, . . . , im/om) be a sequence of input/output actions. We define 
the input actions of the sequence p, denoted by input s(p), as the sequence 
(q, . . . ,im), and the output actions of the sequence p, denoted by outputs(p), 
as the sequence (01, . . . , o m ). 
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Let H = { (pi , n), . . . , {pm, fm)} be a set of pairs (trace, natural number) and 
p = (*i/oi, . . . , i n / o n ) be a trace. The set of input prefixes of p in H, denoted 
by IPrefi x(H,p), is defined as 



IPref ix(7L, p) 



c p'y ) 



inputs)/?) = inputs)//) A r' > 0 A 

r' = £{r" | {p",r") € H A Pref ix(p', p")\ 



□ 



Next we present the notions that we will use to denote that a given event 
has been detected in an implementation. 

Definition 10. Let X = {S, I, O , <5, so) be a PFSM. We say that {ii/oi , . . . , i n /o n ) 
is an execution of 1 if the sequence {ii/oi, . . . , i n /o n ) can be performed by X. 

Let pi,...,p n be executions of X and n, . . . , r n £ IN. We say that the set 
H = {(/?i, ri), . . . , {p n , r n )} is an execution sample of X. □ 

Intuitively, a pair (/?, r) denotes that the trace p has been observed r times. 

Now we have the necessary notions to introduce our new implementation 
relations based on samples. In these relations, the non probabilistic constraint 
is exactly that of the previous one given in Definition 8. Thus, we require that 
the implementation does not invent any behavior that does not exist in the 
specification (i.e. the implementation does not show any output that cannot be 
performed by the specification). Let us remark that this constraint could be 
rewritten in probabilistic terms: The confidence we have on the fact that the 
implementation will not perform forbidden behaviors is 1. However, let us note 
that no hypothesis contrast can provide full confidence on the complete absence 
of a given event. So, it is preferable to keep the constraints over actions separated 
from the probabilistic constraints and deal with them in the classic way, that 
is, an implementation is incorrect with respect to forbidden behavior if such 
a behavior is detected. 

Regarding the probabilistic constraints of the specification, the new relations 
will express them differently to the way we used in Definition 8. In the new set- 
ting we put together all the observations of the implementation. Then, the set 
of samples corresponding to each trace of the specification will be composed by 
taking all the observations such that the trace is a prefix of them. By doing so we 
will be able to compare the number of times the implementation has performed 
the chosen trace with the number of times the implementation has performed 
any other behavior. We will use hypothesis contrasts to decide whether the prob- 
abilistic choices of the implementation conform to the probabilistic constraints 
imposed by the specification. In particular, a hypothesis contrast will be applied 
to each sequence of inputs considered by the specification. This contrast will 
check whether the different sequences of outputs associated with these inputs 
are distributed according to the probability distribution of the random variable 
associated to that sequence of inputs in the specification. In the next definition 
we introduce our first implementation relation based on samples. 
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Definition 11. Let S be a specification and 2 be an implementation. Let H be 
an execution sample of 2 and let 0 < a < 1. We say that 2 ( a , H)— probabilistically 
conforms to S, denoted by Xconfp^’^iS, ifZconf6> and for any p £ Traces (S) 
we have 7(^5, R) > n, where it = inputs(p) and R = {(outputs(p'), r) | r ) £ 

IPrefi x(H,p)}. □ 

In the previous relation, Q denotes the symbolic random variable associated 
to the PFSM S and the sequence of input actions 7r given in Definition 6. Let 
us remind that this symbolic random variable shows the symbolic probability 
associated to the traces with the sequence of input actions 7r in the specifica- 
tion. Besides, each trace observed in the implementation will add one instance 
to the accounting of each trace being a prefix of it. We could consider an alter- 
native procedure where traces are independently accounted and each observed 
trace does not affect the number of instances of other traces being prefix of it. 
However, this method would lose valuable information that might affect nega- 
tively the quality of the hypothesis contrasts. Let us note that the reliability of 
any hypothesis contrasts increases with the number of instances included in the 
samples. Besides, as we said before, an observation where (01, . . . , o n ) has been 
produced in response to (i 1, . . . ,i n ) is indeed an observation where, in particu- 
lar, (01, . . . , Oj) has been produced in response to (H, . . . , ij ), with j < n. So, by 
accounting prefixes we properly increase the number of instances processed by 
hypothesis contrasts, which makes them more precise (as well as the probabilistic 
implementation relation that takes them into account). 

The previous idea induces the creation of a new implementation relation 
that is a refinement of the previous one. Let us note that the probability of 
observing a given trace decreases in general as the length of the trace increases. 
This is so because more probabilistic choices are taken in long traces. Besides, 
taking prefixes into account increases the number of instances of short traces 
more than the number of long traces. Thus, it is likely that the number of short 
traces applied to the hypothesis contrasts of the previous relation will outnumber 
that of longer traces. For example, let us suppose that the sequence of outputs 
(01,02) has been observed 51 times in response to (11,12), while the sequence 
(05,06) has been observed 49 times in response to the same input sequence 
(*1,12). Then, it would be feasible that the number of times (01, 02, 03, 04) was 
detected in response to (*i, *2, *3, *4) is 11, while (05, 06, 07, os) was detected 9 
times. Similarly, the number of instances of other sequences of four outputs 
would be lower than those of two outputs. Let us note that statistical noise 
effects are higher when smaller sets of samples are considered. If we consider 
the previous example, a hypothesis contrast is more likely to be imprecise in the 
case of the traces having length four. Moreover, if we consider extremely long 
traces we could obtain a couple of instances or even none in each class of events 
to be considered by a hypothesis contrast, which would ruin the result of such 
contrast. Taking these factors into account, in the next definition we introduce 
a new implementation relation where the confidence requirement is relaxed as 
the length of the trace growths. This reduction is defined by a non- increasing 
function associating confidence levels to the length of traces. 
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Definition 12. Let / : IN — > R + be a strictly non-increasing function. Let S be 
an specification and I an implementation. Let H be an execution sample ofZ. We 
say that X (/, H)— probabilistically conforms to S, denoted by X confp ( L ff ' S , 
if X conf S and for any p £ Traces(iS) we have R) > f(J), where tt = 

input s(p), l is the length of input s(p), and R = {(outputs(p'), r) \ {p',r) £ 
IPref ix(U, p)}. □ 

6 Conclusions and Future Work 

In this paper we have presented a validation methodology to check whether an 
implemention properly follows the behavior described by a specification. We have 
considered a framework where the specifications of systems contain probabilistic 
information. In order to improve the expressivity of specifications, this quantita- 
tive information is given in terms of symbolic probabilities. That is, probabilities 
are intervals of values instead of fixed values. This feature increases the com- 
plexity of the validation methodology, as it is impossible to infer the actual 
probabilities associated with implementations from a set of interaction samples. 
In order to cope with this problem we have defined two implementation rela- 
tions based on samples. For any given trace performed by the implementation 
we compute the symbolic probability of the specification to perform it and we 
compare this value, by using hypothesis contrasts, with the number of times that 
a particular trace appears in the execution sample. The main difference between 
both implementation relations is how the hypothesis contrasts are applied. 

We are developing a testing methodology so that our implementation rela- 
tions can be checked by applying a set of tests derived from the specification to 
the implementation under test. Besides, we would like to study the integration 
of this framework within that presented in [12], where a testing methodology for 
stochastic-timed processes is introduced. 
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Abstract. Passage time densities are useful performance measurements 
in stochastic systems. With them the modeller can extract probabilistic 
quality-of-service guarantees such as: the probability that the time taken 
for a network header packet to travel across a heterogeneous network is 
less than 10ms must be at least 0.95. In this paper, we show how new 
tools can extract passage time densities and distributions from stochastic 
models defined in PEPA, a stochastic process algebra. In stochastic pro- 
cess algebras, the synchronisation policy is important for defining how 
different system components interact. We also show how these passage 
time results can vary according to which synchronisation strategy is used. 
We compare results from two popular strategies. 



1 Introduction 

Probabilistic quality-of-service guarantees underpin most commercial SLAs (ser- 
vice level agreements): e.g. the probability that a 10-node cluster should be able 
to process 3000 database transactions in less than 6 seconds should be greater 
than 0.915; or a train service should not run more than 10 minutes late more 
than 20% of the time. Whether these commercial guarantees are met or bro- 
ken depends on the aggregate time behaviour across a whole system of complex 
interactions. 

It is frequently useful to model these systems with a process model and 
still further convenient to let individual process actions have random delay: this 
random delay might represent either incomplete or uncertain knowledge on the 
part of the modeller, or a good approximation to underlying aggregate complex 
but deterministic dynamics or genuine random behaviour. 
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All these factors combined point to the conclusion that a stochastic process 
algebra (SPA) such as PEPA [1], EMPA [2] or IMC [3] is an appropriate mod- 
elling tool for many commercial and industrial problems. In this paper we use 
Hillston’s Performance Evaluation Process Algebra (PEPA). 

Traditionally, SPAs like PEPA have been analysed for mean statistics or 
steady-state values [4, 5, 6, 7, 8] with later extensions to transient (time- varying) 
measures with techniques such as uniformisation [9] . Here we not only show how 
complete passage time densities can be extracted but also how such passage 
times are affected by the choice of synchronisation strategy. 

A synchronisation strategy defines how the components of a process algebra 
model interact. In SPAs which just employ Markovian transitions it is a dis- 
tinguishing feature of the different SPAs [10]. Here we compare two popular 
strategies in PEPA: 

minimum rate strategy from [4], which is easy to implement and understand 
and is used in most tool implementations. It can occasionally distort global 
rates of enabled actions. Also implemented in Mobius [11] and PRISM [12]. 
apparent rate strategy from [1], which has the benefit of making certain 
equivalences congruences and precisely represents the minimum rate at the 
global state space level. It is implemented in ipc [13]. 

Given that these strategies can have an effect on the end performance statistics of 
a model, it is important to quantify this effect and understand when differences 
may occur. 

The paper is organised as follows: in Section 2 we discuss the background 
to the choice of synchronisation strategies; in Section 3, we describe the PEPA 
stochastic process algebra; in Section 4, we demonstrate passage time extraction 
from a PEPA model and in Section 5 we present a taxonomy of instances of 
when the synchronisation models differ in behaviour and results. 



2 Background 

In this section, we discuss the idea of a synchronisation strategy for stochas- 
tic process algebras. As described by Milner [L4], sequential or serial mod- 
elling formalisms contrast with concurrent ones such as process algebras because 
the former use the operator/ operand paradigm and the latter use the coopera- 
tor/cooperand paradigm. That is, concurrently active components are peers who 
cooperate and share work such that each participates actively in the shared ac- 
tivity. This naturally gives rise to questions such as “when P can perform a at 
rate rq and Q can perform a at rate r 2 ; and what is the rate at which a occurs 
when they cooperate to perform it?” The answer to this question is given by the 
synchronisation strategy of the process algebra. 

There are many plausible definitions for a synchronisation strategy for a 
stochastic process algebra (see [15, 16] for a fuller discussion of this issue) but 
for a Markovian process algebra (MPA) — restricted to using only exponential 
distributions for rates — some possibilities are ruled out for the technical reason 
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that an arbitrary combination of two exponential distributions is not necessarily 
an exponential distribution. For this reason some MPAs (such as TIPP [17]) 
chose functions for synchronisation strategies primarily because they satisfied 
the algebraic requirement that the chosen function produces an exponential dis- 
tribution when applied to two exponentials. One such function is rate product, 
which was the choice of the designers of the TIPP language. 

However, to use rate product as the synchronisation function does not accord 
well with our intuitions about the physical world and in fact essentially the only 
reason to choose rate product is because of its algebraic properties. To explain 
with an example, if we consider a print spooler which can spool PostScript 
files at a rate of a hundred pages per minute and a printer which can render 
them at a rate of ten pages per minute then the TIPP prediction is that when 
these components synchronise then the resulting assembly will be able to print 
a thousand pages per minute! The PEPA process algebra would instead say that 
the combination would print ten pages per minute (because the faster component 
is hindered by the slower one). This is in accord with our expectations and our 
experience of how the bottleneck device in the system limits the throughput of 
the whole. 

Further, our spooler and printer illustration is not an isolated pathological 
example. An earlier study [16] showed that the performance results computed 
from the use of rate product as a synchronisation strategy could be arbitrarily 
wrong. The same paper went on to show that the strategy used by PEPA pro- 
duced results which were in good agreement with a range of other reasonable 
synchronisation disciplines such as first-to-finish and last-to- finish. 

The technical definition which provides PEPA with this intuitive behaviour 
when components synchronise is that of the apparent rate defined by Hillston [1] 
and adopted by other process calculi such as the Stochastic 7r-calculus [18]. 
Hillston’s apparent rate calculation is perhaps the simplest function which si- 
multaneously satisfies the two key requirements of: 

1. building an exponential distribution when applied to two exponentials; and 

2. computing numerical results which accord with our intuitions of synchronis- 
ing timed activities. 

However, the computation of the apparent rates of the transitions of a PEPA 
model must be performed efficiently if the (perhaps large) state-space of the 
model is to be derived effectively. In order to avoid the cost of this calculation it 
is tempting to approximate the apparent rate with the minimum rate. The novel 
contributions of this paper are the discussion of the cost of computing apparent 
rates and the comparison of the correct calculation of apparent rates with their 
approximation by minimum rates. 

3 PEPA 

PEPA [ ] is a parsimonious stochastic process algebra that can describe com- 
positional stochastic models. These models consist of components whose actions 
incorporate random exponential delays. 
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The syntax of a PEPA component, P, is represented by: 

P ::= (a,A).P | P + P | P IX] P | P/L | A ( 1 ) 

(a, A).P is a prefix operation. It represents a process which does an action, a, 
and then becomes a new process, P. The time taken to perform a is described 
by an exponentially distributed random variable with parameter A. The rate 
parameter may also take the value T, which makes the action passive in 
a cooperation (see below). 

Pi + P2 is a choice operation. A race is entered into between components Pi 
and P2. If Pi evolves first then any behaviour of P2 is discarded and vice- 
versa. 

Pi P2 is the cooperation operator. Pi and P2 run in parallel and synchro- 
nise over the set of actions in the set S. If Pi is to evolve with an action 
a G S, then it must first wait for P2 to reach a point where it is also capable 
of producing an a-action, and vice-versa. In a cooperation, the two compo- 
nents then jointly produce an a-action with a rate that reflects the slower of 
the two components ( R in Figure 1 ). 

P/L is a hiding operator where actions in the set L that emanate from the 
component P are rewritten as silent r-actions (with the same appropriate 
delays). The actions in L can no longer be used in cooperation with other 
components. 

A is a constant label and allows, amongst other things, recursive definitions to 
be constructed. 



Cooperation (Non-synchronising) 



P P' 

pttQ KA) > P' EX] Q 



a £ S 



Q^Q' 

iTA bgS 

P&fQ — 1 — - P ^ Q' 

Cooperation (Synchronising) 

p p' Q ( A£) Q> 

(Tk i a G S' 

P IX] Q 1 > P' IX] Q> 

where R = min(r 0 (P),r 0 (Q)) 



Fig. 1. An excerpt from the operational semantics for PEPA, showing only details of 
the cooperation operator 
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The synchronisation strategy effects the cooperation operator Pi 1X1 P 2 . The 
difference between the apparent rate strategy and minimum rate strategy occurs 
when either Pi or P 2 enable multiple a-transitions, where a £ S. In [1], the 
apparent rate semantics are defined as in Figure 1, where: 

r a (P)= Y, ( 2 ) 



where A * £ 1R + U {nT j n £ (Q, n > 0}, nT is shorthand for n x T and T 
represents a passive action rate that will inherit the rate of the coaction from 
the cooperating component. T requires the following arithmetic rules: 



mT < nT : for m < n and m, n £ 
r < nT : for all r £ 1R, n £ Q) 
rnT + nT = (m + n)T : m, n £ Q) 
mT m 

= — : m, n £ (l) 

nT n 



Note that (r + nT) is undefined for all r £ 1R in PEPA therefore disallowing 
components which enable both active and passive actions in the same action 
type at the same time, e.g. (a, A).P + (a, T).P'. 

The minimum rate strategy is much simpler and is used in many tools [4, 11, 
12] which implement PEPA. The semantics of the joint rate, R, in Figure 1 are 
rewritten as: 

R = min(A,/i) (3) 

for each instance of a cooperating action pair, where X, p £ 1R + U {T} and we 
only need to know that r < T for all r £ 1R + . 



4 Extracting Passage Time Distributions 

In this section, we briefly describe how passage time results are extracted from 
SPA models, so that the reader may better understand the analysis process and 
the sort of quantitative results that are obtained. 

Passage time densities in stochastic models are defined by their source and 
target states, i.e. the time taken to get from one set of states to another. Process 
algebras use transitions or actions as their central descriptive philosophy with 
states only implicitly occurring “between” actions, so we need a technique for 
moving between these two paradigms: i.e. extracting the source and target states 
for the passage in a way that can be easily related to the action-model of the 
process algebra. 

It is convenient to define passage time densities in PEPA models by means 
of fragments of process algebra known as stochastic probes [19]. These probes 
specify the actions that should be seen in order to start and stop the passage time 
measurement and they can easily be interrogated to identify source and target 
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A = (run, Xi ).(stop, Ag).A 
B = (run, T). (pause, As). B 
Sys 0 ® A { jX] } B 

Fig. 2. PEPA description for model Syso — a simple two component system cooper- 
ating over the run action 



Probeidie — (stop, T).Probe run 
Probe run = (stop, T). Probeidie 
Sy Sl = Probe { B< } Sys 0 

Fig. 3. PEPA version of the stochastic probe for model Syso: toggles between started 
and stopped states according to whether it has observed a stop action or not 



actions for the passage. It is important that the probe does not affect the time- 
behaviour of the model it is measuring, so it only presents passive actions for the 
model to synchronise with and it does not block actions it is not interested in. 

In fact, stochastic probes are SPA-independent and can be tailored to any 
SPA which supports multi-way synchronisation between processes (so that one 
can probe the key passage activities). PEPA suited our needs here as it has an 
uncomplicated syntax which lends itself to describing the underlying concepts 
behind stochastic probes. As we will see, the probe is expressed as a single PEPA 
component, so that it can then be combined with the model being queried. 

Figure 2 describes a very simple model with two components A and B. A can 
perform a run then a stop before becoming A again; whereas B can perform 
a run then a pause before becoming B again. The two components synchronise 
over the run action, with the overall rate of the run action being dictated by 
Aj from the A component (since B’s run action was passive, represented by the 
T symbol). We will briefly discuss the derivation of the passage time between 
successive stop actions in this model (a detailed discussion of passage times and 
stochastic probes can be found in [19, 20]). 

Figure 3 shows the stochastic probe that is composed with the Syso model. 
This simple version of a probe just toggles state every time it observes a stop 
action. When we examine the PEPA model of Figure 2 with the Imperial PEPA 
Compiler (ipc) [13], it automatically generates the probe of Figure 3 and inserts 
the state-based logic to define the passage time between successive stop actions. 

ipc's output is in a form readable by Dingle and Knottenbelt’s HYDRA 
tool [21, 22, 23] which can then compute both the probability density function 
(PDF) and the cumulative distribution function (CDF) shown in Figures 4 and 5. 
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Fig. 4. Probability density function for 
time taken between successive stop ac- 
tions in model Syso 



Fig. 5. Cumulative distribution function 
for time taken between successive stop 
actions in model Syso . Shows that prob- 
ability of successive stops occurring in 
less than 3.54 seconds is 0.8893 



In this first example, there is only one possible run synchronisation (derived 
from exactly one active participant and exactly one passive participant) and the 
two synchronisation strategies considered in Section 3 (active and minimum) 
have identical behaviour in this situation. 

In the next section, we will look at small variations of this model which 
add extra possibilities for synchronisation, in order to create a divergence in 
behaviour between the minimum rate and active rate strategies. It is this diver- 
gence we aim to study in the context of passage time analysis. 



5 Results 



For the analysis in this section we are going to need to compare passage times 
from different strategies. So given two random variables representing distinct 
passages, X\ and X 2 , we construct the quantity: 






Fx 2 (*) - F Xl (t) 
F x 1 (t) 



(4) 



to compare their CDFs, Fx 1 {t) and Fx 2 (t ), at different t- values. For each of the 
models being considered in this section we will look at both the individual PDFs 
as well as the plot over the CDFs. This will give a good idea of the relative 
difference in CDF and thus passage time quantile result. 

We consider three variations on the opening synchronisation example: 

Model A multiple passive actions versus a single active action 
Model B multiple passive actions versus multiple active actions 
Model C multiple active actions versus a single active action 

Passage times are then extracted using the same stochastic probe from Figure 3. 
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A = (run, \i ).(stop, As). A 
B = (run, T). (pause, As). B 
Sys A = A M (B || B) 

Fig. 6. PEPA description for model A 




Fig. 7. Probability density functions for time taken between consecutive stop actions 
in model A for (a) the apparent rate strategy and (b) the minimum rate strategy 



5.1 Model A 

Now we consider a small variation on our first model from Figure 6. Here we 
have two copies of the component B. These act as clients of (the single) A, 
competing for its run activity. Thus there are two possible synchronisations: A 
with the left-hand B; and A with the right-hand B. Each of these has one active 
participant and one passive participant. This synchronisation metaphor has been 
termed an implicit choice because although the PEPA choice operator has not 
been used in the model definition still there is a choice of different partners for 
the run activity. 

In this setting, the apparent rate and the minimum rate will produce different 
results. We plot the two PDFs from these strategies in Figure 7 as we probe the 
duration between consecutive stop actions in the model. In Figure 8, we plot 
the percentage difference between these, as carried through to the CDF function: 
l00i/j(X ars , X mrs ,t) for X ars being the passage variable for the apparent rate 
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Fig. 8. Model A: Percentage difference from minimum rate strategy as carried through 
to the CDF 



strategy and X mrs being the passage variable for the minimum rate strategy. We 
note that it is never more than 9% and that it falls off rapidly as time increases, 
dropping under 1% within 6 seconds. 

5.2 Model B 

We consider a third variant on this simple model; Model B in Figure 9. We 
introduce additional copies of the A component, which plays the role of the 
server in the model. Now there are three servers (three copies of A), which is 
a change, and two clients (two copies of B), which is as it was in the previous 
version of the model. All of the servers are independent, as are all of the clients. 
Now there are six possible types of run action, with each of the As synchronising 
with each of the Bs. 



A = (run, Xi ).(stop, Ag).A 
B = (run, T). (pause, As). B 
Sys B ^(A|| A|| A) { M } (B||B) 



Fig. 9. PEPA description for model B 
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Fig. 10. Probability density functions for time taken between consecutive stop actions 
in model B for (a) an apparent rate strategy and (b) the minimum rate strategy 




Time, t 

Fig. 11. Model B: Percentage difference between the minimum rate strategy and the 
apparent rate strategy as carried through to the CDF function 



Again we plot the PDFs of both the model using the apparent rate compu- 
tation and the model using the minimum rate (in Figure 10) and the percent- 
age difference between these as carried through to the CDF (in Figure 11) as 
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A = (run, Aj).(stop, Ag).A 
B = (run, fj,i ). (pause, As). B 
Sysc^A^ (B||B) 

Fig. 12. PEPA description for Model C 



lOO'0(A ars , X mrs ). Here the agreement is even more encouraging and the results 
are even better. The difference between the two plots is never more than 6% and 
the difference reduces to zero even more quickly (within about 4 seconds). 



5.3 Model C 

There is a final PEPA synchronisation idiom which we have not considered, 
which is when both of the partners in a synchronisation contribute actively to 
the result. Such a model is Model C, in Figure 12. Now B is an active participant 
in the run action and is no longer a client of A. Again the differences between 
the apparent rate calculation and the minimum rate calculation are computed 
(and plotted in Figures 13 and 14). The percentage difference between these is 
plotted in Figure 15. This time the calculations are repeated for five different 
values of the rate while holding the value of Aj = 1.0 constant. 

The difference between the two computations is greatest for slower rates 
(low values of hi ) and least for faster rates (high values of hi). When Hi has 
the value 0.8 the difference between the two values is not more than 3% and 
again reduces to zero very quickly (within about 4 seconds) showing that even 
in this case the approximation provided by the minimum rate is acceptable. Not 
displayed is the passage difference, V’('), f° r Mi = 1-0, which is 0 throughout, 
i.e. the strategies produce the same results when the synchronising rates are the 
same. 

6 Conclusions 

ipc [13] is a compiler for PEPA which carefully supports aspects of the PEPA 
language definition which have been approximated by other tools, in particular 
the crucial definition of apparent rate, ipc offers in addition the capability to 
specify and, with the aid of HYDRA [20], calculate passage time quantiles from 
PEPA models. 

Using ipc, we have been able to compare different synchronisation strategies 
in PEPA. We have shown that when passive actions are involved, the minimum 
rate strategy tends to overestimate the global rate of action evolution. This 
translates into a slightly increased probability of early completion in passage 
time measures, as can be seen by the positive difference measure in Figures 8 
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Fig. 13. Probability density functions 
for time taken between consecutive 
stop actions in Model C for 1.0 > p > 
0.05, using the apparent rate strategy 




Fig. 14. Probability density functions 
for time taken between consecutive 
stop actions in Model C for 1.0 > p > 
0.05, using the minimum rate strategy 




Time, t 

Fig. 15. Model C: Percentage difference between the minimum rate strategy and the 
apparent rate strategy as carried through to the CDF functions for 5 different values 
of pi 



and 11. Conversely, in active synchronisations, we have shown that the minimum 
strategy results in a slightly decreased probability of early completion. 

It would appear that, except in cases where the Markov chain is stiff (has rates 
of orders of magnitude difference) , the differences in strategy are neither too large 
nor too long-lasting. It should be borne in mind that we have deliberately taken 
worst case scenarios of synchronisations that reoccur very frequently and that 
in larger models where the synchronisations are more separated, the differences 
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in performance metrics are likely to be very small. As future work, we intend to 
look at how synchronisation affects larger models of system behaviour. 

User experience tells us that the computation of apparent rates is a notice- 
able overhead on state-space generation time and so a reasonable methodological 
approach might be to work with the approximation to the apparent rate com- 
putation for swift initial investigation of the problem before progressing to the 
more accurate (but more expensive) calculation later. In this way, reasonable 
performance results can be obtained quickly while the PEPA model is being 
developed and debugged and the performance modeller can progress to a more 
careful calculation of performance metrics after this initial development phase 
has ended. 
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Abstract. A True Concurrency Timed Process Algebra which takes into 
account the number of resources/processors that processes have at dis- 
posal is presented. Both its syntax and its operational semantics are 
defined. An algorithm which allows us to estimate the required time to 
evolve between states and which allows us to evaluate the performance 
of a system is also presented. A simple example is used to illustrate 
how a system can be specified by means of our language and how the 
performance evaluation algorithm works. 



1 Introduction 

It is a well-known fact that concurrency involves a radical increase in the com- 
plexity of a system. Theoretical models to study these systems at a formal level 
became of great importance. The first models abstract many real properties of 
concurrent systems which are considered non essential for them, such as duration 
and structure of actions, properties of communication networks, distribution of 
system components, number of processors and so on. By leaving these non essen- 
tial properties aside, it is easier to study the behaviour of processes at a formal 
level due to a clearer design specification. However, these simplifications have 
a cost which is the loss of all the information which has been abstracted. This fact 
can be observed in early formal models such as Petri nets and process algebras. 

Once the basic models have been thoroughly studied, it is necessary to extend 
them to deal with these other aspects, usually quantitative ones, which have been 
lost in the abstraction. Extended models have been proposed to represent aspects 
such as fairness [1, 2], timed models [3, 4], Markovian timed models [5, 6] and 
probabilistic models [7, 8, 9]. 

The aim of this paper is to introduce a timed process algebra, called BTC 
(for Bounded True Concurrency), which allows us to evaluate the performance 

* This work has been partially supported by the MCyT project “Description and 
Performance of Distributed Systems and Application to Multimedia Systems” (Ref. 
TIC2003-07848-c02-02) and the JCCM project “Design and Implementation of Effi- 
cient Multimedia Systems by using Formal Techniques” (Ref. PAC-03001). 



M. Nunez et al. (Eds.): FORTE 2004 Workshops, LNCS 3236, pp. 143—155, 2004. 
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of a system, considering that the (limited amount of) available processors have 
to be shared by all the processes. We can generalised this approach and consider 
systems that share homogeneous resources of any kind (processors, buses, disks, 
etcetera). Nevertheless, we cannot consider yet processes that need to use het- 
erogeneous resources (e.g. one processor unit and two disk units). This extension 
of the process algebra is left for future work. 

The most important consequence of this approach is that if there are more 
processes than resources then not all of them can be simultaneously executed. 
A process has to wait until it allocates the resources needed to continue its 
execution. This means that we can find two kinds of delays in the execution of 
a process: delays related to the synchronization of processes, and delays related 
to the allocation of resources. The former is usual in a (theoretical) concurrent 
context, but the latter is only taken into account if we consider a limited amount 
of available resources. 

In order to present our model, it is worth to review an important character- 
istic of the currents formal models of concurrency. They can be roughly divided 
into two groups: Interleaving based models, in which the independent execution 
of two processes is modelled by specifying the possible interleaving of their ac- 
tions; and true concurrency models, in which the causal relations between actions 
are explicitly represented. Our process algebra is based on the notion of true con- 
currency where concurrent behaviour can be distinguished from interleaving one 
by considering that (a|6) ^ (a. b+ b.a) 

Furthermore, the bounded true concurrency approach we present in this pa- 
per considers all the cases between interleaving based models and true concur- 
rency based models. In particular, if we consider only one resource unit, we will 
be considering an interleaving approach, while if we consider infinite resources 
we will have a true concurrency approach. From this point of view, our model 
extends both interleaving and true concurrency based models. 

The performance of a system may be different depending on the number of 
available resources. If we denote by [P]at a process which is executed in the scope 
of N resources, we will have that [a|6]i = [a.b + b.a ] i but [a\b] n ^ [a.b + b.a] n 
Vn > 1. In general, given a process P, Vn, m (E N with n ^ ?n, we have that 
the performance of [P] n may be (or may be not) different from the performance 
of [P]m- Actually, one of the main applications of this process algebra consists 
in finding a natural number n such that Vi £ N,i > n, [ P]i is equivalent (from 
a performance point of view) to [P]„, i.e., n represents the maximal degree of 
parallelism we can exploit in the system, and as a result, we obtain the optimum 
number of resources needed in order to speed up the performance of the system. 

BTC is based on CSP [10]. We have extended its syntax in order to con- 
sider duration of actions by means of a timed prefix operator. The operational 
semantics has been also extended in order to consider the context (number of re- 
sources) in which processes are executed. A notion of timed bag of actions is also 
introduced to represent the concurrent (simultaneous) execution of processes. 

In the literature we may find several theoretical models that consider the no- 
tion of resource consuming. Timed process algebras that consider resources are 
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presented in [11, 12, 13, 14, 15, 16]. In [11, 12] a discrete timed process algebra 
for limited parallelism (CCSLP) is presented. Time is associated to actions by 
considering special actions t n where n represents the consumption of n (homo- 
geneous) resource units. This means that, if we want to specify an action that 
lasts 2 units of time, we have to write a.ti.t\.NIL , where a does not represent 
the execution of the action but just the moment in which the action starts its 
execution. From our point of view, the main problem of that model is that it may 
be difficult to know when an action finishes. If we consider three actions (a, b, c) 
with duration 2 (i.e., a.t\.t\.NIL, b.t\.t\.NIL, c.t\.t\.NIL), and two resources 
(processors), a possible sequence of actions is a.b.t 2 -c.t 2 -t 2 , where the first 1 2 
represents the execution of the first unit of a and b , the second £2 represents the 
execution of the first unit of c and the second unit of a or 6, and the last t 2 
represents the execution of the second unit of c and the second unit of b or a. 
Thus, it is difficult to analyse the performance of a system because it may be 
impossible to know when the system has reached a state. 

In [13] a process algebra for shared processors is presented. The paper is 
focused on processes sharing a single processor scheduled according to some 
scheduling strategy. Multi-processors systems can be described but only with 
static allocation of processes to processors. This situation does not happen in our 
model where there is no assignment of processes to processors, i.e., a sequential 
process may be interrupted and later on it can continue its execution in a different 
processor. 

ACSR, a process algebraic approach to the specification and analysis of 
resource-bound real-time systems is introduced in [14]. In that process alge- 
bra, the use of shared (heterogeneous) resources is represented by timed actions 
and synchronization is supported by instantaneous events. Timed actions are 
always executed for one time unit (tick) and they consume a set of resources 
during that time. ACSR supports also priorities which are used to decide among 
processes (actions) competing for resources. In [15] an extension of ACSR con- 
sidering dense time is presented. In that model, timed actions have a duration 
given by a positive and finite real number u, where A u represents the execution 
of a resource-consuming action A for a time u. Synchronization between timed 
actions is allowed but only in the case that both actions have the same duration 
and they use disjoint sets of resources. Other extensions of ACSR are presented 
in [16] where PACSR (probabilistic ACSR) and ACSR- VP (ACSR with value 
passing) are introduced. 

The approach taken in ACSR and extensions is slightly different from ours. 
In ACSR, a timed action is a set of pairs (resource, priority), and two (or 
more) timed actions may be executed simultaneously only if they use different 
resources. Let us consider a system with two processors. If we have three pro- 
cesses that use different resources, then the three processes may be executed 
simultaneously, but, actually, we have only two processors. In order to consider 
that there are only two available processors, we need to consider two resources, 
cpul and cpu2, each one representing one processor (in ACSR it is not allowed to 
have two units of a resource). As an example we can consider the following three 
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processes (in ACSR syntax): P = {(cpitljl)} 1 : NIL, Q = {(cp^l)} 1 : NIL 
and R = {(cpul,!)} 1 : NIL. Then we have that in the first step P and Q 
or R and Q may evolve simultaneously, but not P and R because they share 
the resource cpul. In other words, resources are statically assigned to processes. 
This does not occur in our model where resources are dynamically assigned to 
processes. 

A different approach is considered in [17] where a process algebra for the 
management of resources in concurrent systems (PARM) is presented. In that pa- 
per a heterogeneous resource context and a resource trading policy (based on 
utility functions) are introduced. The main idea is that several processes can 
exchange resources in order to improve the performance of the global system, 
provided that none of them can get worse after the exchange. Although this is 
a very interesting work, it is not very closed to our approach because no quan- 
tification about the performance of a system is considered. A related approach is 
considered in [18] where an optimal resource allocation in multi-class networks 
scheme is presented. 

The rest of the paper is organised as follows. First, we present the syntax of 
BTC and some basic notations. Next, the operational semantics of the language 
is defined by means of a set of inference rules. Building on it, we define an 
algorithm for performance evaluation and illustrate it with a simple example of 
how a system can be specified and how the performance algorithm works. Then 
we present our conclusions and outline some lines for current and future work. 



2 Introducing the Language BTC 

In this section we introduce the process algebra BTC by means of its syntax 
and an intuitive interpretation of the operators. 

Definition 1. Let Actx be a finite set of timed actions and Actjj a finite set 
of untimed actions, Actjj D Actx = 0- The syntax of BTC is defined by the 
following BNF expression: 

P ::= stop | a.P \ <b, a>.P \ P ® P | P + P | P ||a P | recX.P 

where A C Actjj, a £ Actjj, b £ Actr, and a £ N, where N represents the set 
of natural numbers. Furthermore we assume a set of process variables Id ranged 
over by X, X' , a set of processes V ranged over by P, Q, R, and a set of actions 
Act = Actjj U Actr- 

Let us now informally describe the interpretation of these operators. Later 
we will provide them with an operational semantics, so the meaning of each 
operator and the relationship among them will be completely formalised. 

stop. This represents a deadlock, that is, no action can be executed. 

Prefix. This is the classical prefix operator. It will we use to represent a pro- 
cess P prefixed by an untimed action. As usual, the process a.P, once the 
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action a has been executed, behaves like the process P. Mainly, we will 
use the (untimed) prefix operator to represent a possible synchronization of 
a process. 

Timed prefix. The classical prefix operator has been enriched with information 
about the amount of time the action b takes in its execution (the value a). 
The process <b, a>.P , once the action b has been executed, behaves like the 
process P. 

Internal choice. This is essentially the classical internal choice operator. Given 
two processes Pl and P 2 , P\ © P 2 represents the process that behaves like P\ 
or like P2 as the result of an internal decision of the system. 

External choice. This is also interpreted in the usual way. Given two pro- 
cesses Pi and P2, Pi + P2 represents the process that behaves like Pi or 
like P2 as the environment requests. 

Parallel composition. Pi || 4 P2 represents the parallel execution of the pro- 
cesses Pl and P2, where they synchronize on the actions in A. We will denote 
by Pi || P2 the parallel execution of Pl and P2 without synchronization, that 

is, Pi || {} P 2 - 

Recursion. The process recX.P represents the classical recursion operator 
where occurrences of X are substituted by recX.P. This operator allows 
us to define infinite behaviours. 



During the rest of the paper we will use the following notation to deal with mul- 
tisets (bags). We will use the convention that B = {2.xi, 3. £2, 5. £3} represents 
the multiset defined over the set X = {xi, X 2 , x 3 , 24} by: 

B : {xi, x 2 , x 3 , 24} — > N 



B(x 1) = 2, B(x 2 ) = 3, B(x 3 ) = 5, B(x 4 ) = 0 

We will use capital letters B, Pi, P2, C, C\, C 2 to denote multisets, while capital 
letters such us A, Ai, A 2 will represent sets. Both the empty multiset and the 
empty set will be represented by 0. We will also use the following operations: 



— Pi U P 2 : Union of multisets. 

— |B| : Number of actions in the multiset, that is, |B| = J2xex^( x )- 

— B fl A : Multiset obtained by taking from P the actions belonging to A, that 



is, 



(BnA)(x) 



B(x) if x £ A 
0 otherwise 



Definition 2. Let B{X) = {B \ \/x fL X,B(x) = 0} be the set of multisets over 
the set X. A timed bag is a pair (P,a), where B £ B(X), and a € N is the 
duration of every element in B. The set of timed bags over the set X, denoted 
by TB(X), is defined as TB(X) = {(B, a) \ B £ B(X) A a £ N}. 

Intuitively, a timed bag relates a multiset to a unique natural number that 
represents the time every action (element) in the multiset needs to finish its 
execution. 
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3 Operational Semantics 

In this section we present an operational semantics. By means of this mechanism, 
we provide the language operators with a meaning and an accurate interpreta- 
tion by describing how a process is able to turn into another. This evolution is 
represented by using labelled transition systems. 

We will have that transitions are triples (P,Q,(B,a)). We will usually denote 

transitions by P Q. 

Intuitively, the meaning of the previous transition is that the process P ex- 
ecutes the actions belonging to the multiset B and then it behaves like the 
process Q. The execution of each action belonging to the same multiset takes a 
units of time. 

In order to consider internal (non observable) evolutions of a process, we 
consider a new kind of action, r Act, which represents an internal action. This 
action is used to define the evolution of the internal choice of two processes, and 
it has duration 0. 

In Table 1 we can find the rules of the operational semantics. We assume 
that a, a' £ N, a £ Actu, b £ Actr, Bi £ B(Actl} {r}) and B' £ B(Actu)- We 
also consider a constant Af that represents the amount of processors/resources 
at disposal. 

The rule Rla is the classical one for the prefix operator. The rule Rib states 
that given a process P and an action b with an execution time a, b is firstly 
executed and, after a units of time, the process behaves like P. In rule Rlc 
a partial execution of the timed action b is allowed, i.e., action b is executed for 
a' units of time and the remaining time (a — a') will be performed later on. 

The rule Rlc allows a prefix operator transition to be split into any number 
of consecutive transitions. This rule is very similar to the rule ActT presented 
in [15]. The only difference is that, in that case, a dense time domain is considered 
and, consequently, an infinite number of transitions are derived. In our model 
this does not occur because we work in a discrete time domain. 

The rules R2 and R3 are the classical ones for the internal and external 
choice operators. 

The rule R4 represents the basic synchronization mechanism. We only con- 
sider those synchronization actions that may be performed by processes P and Q. 
As synchronization actions are untimed actions, the whole process evolves in 0 
units of time to P' ||a Q' . 

The rule Rba captures the simultaneous execution of, at most, A f no synchro- 
nization actions. Although we have considered as premises that both processes 
may perform different timed bags with the same time a, this does not represent 
a loss of generality because applying rule I?lc we can split transitions in order 
to have the same time in both premises. 

The rules R5b and R5c are similar to R5a but consider that only one of the 
two processes (P or Q) evolves. 

Finally, the rule R6 captures the semantics for recursion in the usual fashion. 
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Definition 3. The operational semantics of BTC is defined as the least multiset 
of transitions we can derive by using the rules in Table 1 . 



Table 1. Operational Semantics 



Rla) 



a.P 



Rib) 



(6, a).P ^’ Q » P 



Rlc) 



0 < a < a 



(b, a).P ^’ Q > (b, a - a').P 



R2a) 



P © Q-^-^P 



R2b) 



P © 



R3a) 



P _BP^ p 
P + Q-^Up' 



R3b) 



Q' 

P + 



R4) 



P B ’° > P' A Q B ’° > Q' A B' = B' n A ^ I 
p IU Q B ' ° > P' IU Q' 



R5a) 



P Bl '° ~ P’ A Q B2,a > Q' A _Bi 0 A = 0 A |Ri| + |B 2 | < A/" 



PIUQ 



R5b) 



P B,a > P' A B n A = 0 
P \\a Q B,a > P' |UQ 



R5c) 



Q B,a > Q' A R n A = 0 

p IU Q B ’ a > p IU Q' 



R6) 



P{recX.P/X} ^’ Q » P' 









recX.P 
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4 Performance Evaluation Algorithm 



With the formal resource-aware model that we have just defined, the timed 
characteristics of the system have been captured. Now we are concerned with 
defining an algorithm which allows us to estimate the minimum time needed to 
reach a given state. 

By applying the rules of the operational semantics, we build a transition 
graph where we can abstract the information about actions and consider only the 
information about time (duration of actions) . This graph is a weighted directed 
graph, where weights are always positive numbers, and finding the shortest path 
from the initial node is the problem we want to solve, problem which is solved 
by using Dijkstra algorithm. 

Let Tsi be the expected time to evolve from the initial state So to a state Si, 
and In(Si) the set of predecessor nodes of Si. For every state Sj £ Jn(S) ) an 
edge labelled by aji which represents the time to evolve from Sj to Si exists. 

Then, Ts { may be obtained by computing recursively the following equation 



f 0 if Si = So 

|^min{Tg. + aji \ Sj £ In(Si)} otherwise 



(1) 



In order to compute (1), we number the n nodes of the graph from 0 to n — 1, and 
we assume it is represented by an adjacency matrix where co.st[i] [j] is defined as 
follows 



cost[i\\j] 



aij if Si £ In(Sj) 
oo otherwise 



Finally, the performance evaluation algorithm is shown in Fig. 1. 



5 A Simple Example 

In this section, we present a simple example of specification using BTC (addition 
of two matrices) . We show the transition graph we obtain by applying the rules 
of the operational semantics, and we compute the minimum and maximum time 
needed to finish the operation depending on the size of the matrices and the 
available processors. 

We assume, without loss of generality, that we have the same number of 
threads/processes as rows (columns) in the matrices to sum. This system can be 
modelled as follows: 



System = Pi || P 2 || . . . || Pi || . . . || P n 
Pi = (rdi,4:).(addi,l).(wri,2).stop 

where rdi is an action meaning ’’read a row”, addi is ’’add a row” and wri is 
” write a row” . 

Figure 2 shows the transition graph we obtain when we consider two matrices 
with just three rows in a system with two processors ( J\f = 2). Taking into 
account the symmetry in the three possible paths from the initial node, just one 
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MinTime(int v, int cost [] [] , int n, int dist [] , bool S [] ) { 

// v: initial node 

// cost: adjacency matrix with weights 

// n: number of nodes in the graph 

// dist: shortest known path from initial node 

// S: true if shortest path is known 

// big_number: constant which value is a'big number 

int u, minimum; 

for (int i=0; i<n; i++) { 

S[i] = false; dist [i] = cost [v] [i] ; 

} 

S [v] = true; dist [v] = 0; 

for (int num=0; num<n; num++) { 

// Choose u from among nodes not in S such that dist [u] is minimum, 
minimum = big_number ; 
for (int i=0; i<n; i++) 

if ( ! S [i] && (dist [i] <minimum) ) 
minimum=dist [i] ; u=i ; 

S [u] =true ; 

for (int w=0; w<n; w++) // Update distances 

if ( ! S [w] && (dist [w] >dist [u] +cost [u] [w] ) ) 
dist [w] = dist [u] + cost [u] [w] ; 

} 

} 



Fig. 1. Performance evaluation algorithm 



of them has been depicted. For the sake of clarity, we have always chosen the 
biggest number of actions we can execute simultaneously. 

There are several paths in which the required time to do this addition is 
minimum. In the transition graph in Fig. 2 we have marked with dotted lines 
one of them. Every node in this shortest path has a representation in terms of 
BTC as follows: 

N 0 = (rdi, 4).(addi, 1). («iri, 2)| |(rd 2 , 4). (add 2 , 1 ).(wr 2 , 2)|| (rd 3 , 4). (add 3 , l).(wr 3 , 2) 

Ah = (addi, l).(wri,2)||(add 2 , 1). (wr 2 , 2)| |(rd 3 , 4). (add 3 , l).(wr 3 ,2) 

N 3 = (addi, l).(wri, 2)| |(wr 2 , 2)|| (rd 3 , 3).(add 3 , l).(u>r 3 , 2) 

Ng = (add 1 ,l).(wri,2)\\(rd 3 ,l).(add 3 ,l).(wr 3 ,2) 

N 15 = ( wr i,2) 1 1 (add 3 , l).(wr 3 ,2) 

N 2 i = (wr !, l)||(wr 3 , 2) 

N 23 = ( wr 3 , 1) 

N 26 = STOP 

We observe that the minimum time needed to do this addition of matrices is 
11 units of time while if we were to work in a sequential way (or interleaving) 
we would have needed 21 units of time. 
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The same example of the addition of matrices has been developed for various 
matrix sizes and different number of processors, obtaining the results displayed 
in Table 2. 
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Table 2. Sum of two matrices with various matrix sizes and different number of 
processors 



Matrix size 


Processors 


T. Min 


T. Max 


3 


2 


11 


21 


3 


3 


7 


21 


4 


2 


14 


28 


4 


3 


10 


28 


4 


4 


7 


28 


6 


2 


21 


42 


6 


3 


14 


42 


6 


4 


11 


42 


6 


6 


7 


42 


10 


2 


35 


70 


10 


3 


24 


70 


10 


4 


18 


70 


10 


5 


14 


70 


10 


6 


12 


70 


10 


7 


11 


70 


10 


8 


11 


70 


10 


9 


11 


70 


10 


10 


7 


70 



6 Conclusions 

In this paper we have presented a timed extension of CSP, called BTC, which 
allows us to evaluate the performance of a system, taking into account that the 
available resources have to be shared by all the processes. In this first approach 
to the model we have only considered homogeneous resources. 

This algebra can be used for two main different tasks. On one hand, given 
a fixed number of resources, we are able to evaluate the performance of a sys- 
tem. On the other hand, if we start with some specification, we can find the 
appropriate number of resources that we need to fulfil some time requirements. 
We can even calculate the minimum number of resources needed to obtain the 
best performance of a system. This is particularly important in some applica- 
tions (e.g. MPEG2 encoding compression algorithm [19]) where the performace 
of parallel algorithms is measured considering different experimental settings (2, 
4, 8, . . .processors) [20]. 

Although we have found in the literature different approaches to the problem, 
none of them seems to cover the main topic of our model: performance evaluation 
of processes that share resources. 
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7 Future Work 

Our future work is related to extend BTC in order to consider heterogeneous 
resources. In order to define this extension we consider that some of the ideas 
presented in ACSR [14, 15] could be of interest. 

From an application point of view, it would be interesting to link our resource- 
aware model to a tool for standard timed models making the analysis amenable. 
If it were impossible we will consider to design a new tool. 

Another goal is to model (and analyse) a real system. For this aim, we are 
considering some parallel algorithms for image and video compression based on 
Wavelet methods. Compression of visual data is a computationally expensive 
task where large volumes of data have to be processed; therefore compression 
algorithms can greatly benefit from the use of parallel systems. In this setting, 
our algebraic language can be used to find the most appropriate number of 
needed processors for optimum performance. 

Finally, our model suffers from the state explosion problem. We think that it 
could be useful to include some kind of reduction techniques (maybe scheduling) 
in our model which allows the reduction of the graphs. 
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Abstract. Interactive Markov chains (IMCs) are powerful models of 
concurrent systems, and branching time equivalences are useful to com- 
pare the behaviour of concurrent systems. In this paper we define various 
branching time relations on IMCs, including strong and weak (bi)simula- 
tions, and investigate connections among these relations. These relations 
are defined as an orthogonal extensions of classical labelled transition 
systems and pure stochastic settings. The logical characterizations of 
them are also studied by using an action-based logic aCSL. We show that 
for IMCs, bisimulation equivalence coincides with aCSL-equivalence, and 
simulation preorder weakly preserves aCSL safety and liveness formulae. 



1 Introduction 

Bisimulation and simulation relations are used widely to compare the behaviour 
of concurrent systems. They are both known as branching time relations. Bisim- 
ulations are equivalences that relate two states if they exhibit identical stepwise 
behaviour while simulations are preorders requiring one state to mimic another 
state in a stepwise manner, but the reverse does not necessarily hold. Typically, 
there are two distinct types of both simulation and bisimulation, i.e., strong 
(bi) simulations and weak (bi)simulations. Strong (bi)simulations require each 
individual step needs to be mimicked whereas weak (bi)simulations consider 
only observable steps and ignore internal behaviour. 

Originally, simulation and bisimulation relations are defined on labelled tran- 
sition systems (LTS) [20, 21], and their relationship has been studied inten- 
sively [14, 15]. The logical characterizations of these relations are also investi- 
gated based on classical transition systems. For example, strong bisimulation 
coincides with CTL-equivalence [10] and strong simulation agrees with a “pre- 
order” on the universal (or existential) fragment of CTL [11]. Similar results 
hold for weak (bi)simulation where typically the next operator is omitted [22]. 

* Partially supported by National Science Foundation of China (NSFC) under Grant 
No. 60373113. 
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During the last decade, many (bi)simulation relations have been defined on 
probabilistic systems [3, 8, 9, 12, 19, 23], and various logics to reason about 
such systems have been proposed [1, 2, 16]. In the probabilistic framework, 
Markov chains are widely used as system models, including discrete-time and 
continuous-time models. In such frameworks, bisimulation and simulation re- 
lations are efficient means to aggregate the state space, and therefore can be 
useful to solve the well-known state space explosion problem occurring when 
using Markov chains as system models. Bisimulation and simulation relations 
for discrete-time Markov chains (DTMCs) and continuous-time Markov chains 
(CTMCs) have been developed respectively. A logic termed PCTL [ 6], which 
extends CTL with probability, is proposed to characterize DTMCs. For CTMCs, 
another extension of CTL called CSL ( Continuous Stochastic Logic), first pro- 
posed in [1] and then refined in [4, 5, 6], is dedicated to characterize such models. 
However, these works are developed in isolation, and the connections among each 
other have received scant attention. 

This paper attempts to study these branching time relations for stochastic 
system in a uniform framework, especially their interrelation. Furthermore, we 
consider these relations on a more powerful model — interactive Markov chains 
(IMCs) [17]. An IMC is the combination of CTMCs and interactive process, and 
treats interactive transitions and Markovian transitions in a separate way. Due 
to the distinctive representation of action and Markovian transitions, IMCs can 
preserve most advantages of both interactive processes and CTMCs. This makes 
IMCs also a powerful model of performance evaluation. 

The logical characterizations of these relations are also considered in this 
paper. We use an action-based logic called aCSL to specify the logical character- 
ization of IMCs. This logic is a variant of the language using in [18] except that 
the steady-state operator is omitted. The main results are that the strong bisim- 
ulation coincides with aCSL-equivalence while strong simulation preserves aCSL 
safe and live formulae. For weak relations, the similar results also hold where 
the internal action is ignored. Such coincidences with logics are very useful to 
help simplify model checking stochastic models. See e.g. [4, 6]. 

The rest of this paper is organized as follows: Section 2 introduces our system 
model, interactive Markov chains. In Section 3, we define various branching 
time relations on IMCs and investigate connections among these relations. The 
logic characterizations of these branching time relations are studied in Section 4. 
Section 5 concludes this paper. 

2 Interactive Markov Chains 

Interactive Markov chains are proposed by H. Hermanns [17], which combine 
interactive processes and CTMCs together and aim at compositional perfor- 
mance evaluation. This section gives a brief introduction to IMCs, serving as 
our underlying model. 



158 Guangping Qin and Jinzhao Wu 



2.1 Continuous-Time Markov Chains 

IMCs are an extension of continuous-time Markov chains, we therefore first recall 
the basic concept of CTMCs. Let AP be a fixed finite set of atomic propositions, 
and denote the set of non-negative reals. 

Definition 1. A (labelled) CTMC is a tuple C = (S,R,L) where: 

~ S' is a countable set of states, 

— R : S xS-> R^o is a rafe matrix , and 

— L : S — > 2 ap is a labelling function which assigns to each state s £ S the set 
L(s) of atomic propositions that are valid in s. 

Intuitively, R(s, s') > 0 iff there is a transition from s to s' and the probability 
of this transition taking place within t time units is 1 — e -R, ' s,s > ' t , an exponential 
distribution with rate R(s, s'). If R(s, s') > 0 for more than one state s', a race 
between the outgoing transitions from s exists, and the probability of which 
the state s' wins the race is given by P(s, s') = R(s, s')/E(s) where E(s) = 
Y^s'eS R( s > s 0, denoting the total rate at which any transition outgoing from 
state s is taken. More precisely, E(s ) specifies that the probability of leaving s 
within t time units is 1 — e~ E ^' t . If E(s) = 0, we call s an absorbing state, 
and define P(s,s / ) = 0. Consequently, when there exists race condition, the 
probability to move from s to s' within t time units is given by Pt(s,s / ) = 
P(s, s') ■ (1 — e~ E ( s ' ) ' t ). 

2.2 Interactive Markov Chains 

Let Act denote the universal set of actions, ranged over by a,b,- ■ ■. r £ Act , 
denoting the internal action. 

Definition 2. An interactive Markov chain (IMC) is a quadruple 
M = (S, A, — ♦, — ->), where 

— S is a nonempty set of states, 

— AC Act is a countable set of actions, 

— — > c5xxlxSisa set of so called interactive transitions, and 

— --•» C S x R^q x S’ is a set of so called Markovian transitions. 

Here, we restrict the Markovian transitions to further satisfy that for each 
pair of states (si,S 2 ) there is at most one Markovian transition between them. 
We can see that IMCs combine actually the interactive processes and CTMCs as 
orthogonal to each other as possible except that the labelling function of CTMC 
is absent. This means that IMCs are no longer state-based but action-based. The 
interactive transitions correspond to the action transitions of classical labelled 
transition systems, and the Markovian transitions are in fact equivalent to the 
rate matrix R of the CTMC (cf. Definition 1.). Figure 1 is an example IMC. 

In the sequence, we also use RM to denote the rate of exponential dis- 
tribution when there exists a Markovian transition between s and s' such that 
(s, R(s, s'), s') €—*. For CCS, let R(s,C) = £ s 'eC R ( s ’ s/ ) and P(s,C) = 
£ s 'ec R ( s ’ s for simplicity. 
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Fig. 1. An example of interactive Markov chain 



3 Bisimulation and Simulation Relations 

Bisimulation and simulation are the most important and useful branching time 
relations in concurrency theory. Our purpose is to lift these notions to IMCs. 
We consider both strong and weak relations on this model. 

3.1 Bisimulation 

As defined in the definition of IMCs, there are two different kinds of transitions in 
an IMC. How these two different transitions perform when they are both present 
is important. In fact, the executions are governed by the so called maximal 
progress assumption [17]: if the interactive transition is an internal transition, 
then it prevent the Markovian transition. While for observational action, its 
execution may rely on the sojourn time of the state, which is determined by the 
total rate of the state. 

We use s to denote the absence of such internal transitions. Let M = 
(S', A, — >, — ->) be an IMC. Strong bisimulation on IMCs is defined as follows: 

Definition 3. An equivalence relation B on S is a strong bisimulation iff for 
all siBs 2 '- 

1. si — —> sj, a £ A => 3s' 2 € S, S 2 — s' 2 and s) Bs 2 , and 

2. si f—^f => R(si, C) = R(s 2 , C) for all equivalence classes C of B. 

si and s 2 are strongly bisimilar, denoted si ~ s 2 , if there exists a strong bisim- 
ulation B on S with s\Bs 2 - 

Example 1. Figure 2 shows a strong bisimulation equivalence on the given IMC, 
where the states with the same shade are strongly bisimilar. 

Strong bisimulation relation treats internal actions as special only in Marko- 
vian transitions. It does not abstract internal actions from sequence of interactive 
transitions, as weak bisimulation relation on classical labelled transition systems 
does. So we want to lift such weak bisimulation relation to the context of IMCs. 

Let => represents the reflexive and transitive closure of — », and =>• denotes 
=>■ — Note that ==> is possible without actually performing an internal 
action, but =>■ must perform exactly one transition — » proceeded and followed 
by arbitrary (possibly empty) internal actions. 
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Fig. 3. Weak bisimulation equivalence 



Definition 4. An equivalence relation B on S is a weak bisimulation iff for 
all s\Bs 2 - 

1. si = ^ Si,a £ -4\{r} => 3s' 2 £ 5, S 2 ==> s' 2 and s^Bs^, and 

2. Si si, si 7^ => 3s 2 £ S,s 2 si, si and' R(si,C) = R(si,C) 
for all equivalence classes C of £> with C ^ [si]g. 

si and s 2 are weakly bisimilar, denoted si ~ s 2 , if there exists a weak bisimula- 
tion B on S with si$s 2 . 

Note that the second condition is not required to hold for all equivalent class 
but only the equivalent class C with C ^ [si]g. This consideration is similar 
to the weak bisimulation on LTS, where we abstract the internal actions from 
observation. Intuitively, The Markovian transitions in the same equivalent class 
can be seen as internal moves and thus their cumulated rate do not need to be 
calculated. 

Example 2. In contrast with Fig. 2, Fig. 3 shows a weak bisimulation equivalence 
on the given IMC, where the states with the same shade are weakly bisimilar. 

It is not hard to see that in Fig. 3 the weakly bisimilar states are not strongly 
bisimilar. However, in Fig. 2, the strongly bisimilar states can also be considered 
weakly bisimular according to Definition 4. Thus we have: 

Proposition 1. For any IMC and any state si, s 2 £ S, si ~ s 2 implies si ~ s 2 . 

□ 



3.2 Simulation 

Simulation for classical labelled transition systems is defined in terms of simula- 
tion of successor states, i.e. , state s' simulates s if for each successor t of s there 
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s 2 
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Fig. 4. Strong simulation preorder 



is a successor t' of s' that simulates t. For the stochastic behaviours of IMCs, 
we follow the same ideal of [3, 19] to define the simulation relation by means of 
weight functions. Let Dist(S') denote the set of all distributions on the set S. 

Definition 5. Let /t, // £ Dist(S'), R C S x S. A weight function for p and // 
with respect to R is a function A : S x S — > [0, 1] such that: 

1. A(s, s') > 0 implies sRs', 

2. p{s) = K x • J2 s 'es A(s, s') for any s £ S, and 

3. //(s') = K 2 ■ J2 seS A(s, s') for any s' £ S, 

where K\ = Y^seS M s )> AT 2 = Yls’&s rfW)- We wr it e Er // iff there exists 
a weight function for p and p' with respect to R. 

Relation Qr is symmetric if p and p! are both stochastic [3]. A weight func- 
tion is indeed a probability distribution on S x S such that the probability to 
select (s, s') with sRs' is 1. In addition, the probability to select an element in R 
whose fist component is s equals p(s), and the probability to select an element 
in R whose second component is s' equals //(s'). 

Definition 6. A preorder S on A is a strong simulation iff for all snSs 2 : 

1. Si — s^, a £ A => 3s' 2 £ S, S 2 — s' 2 and s] Ss ' 2 , and 

2. si => P(si, •) Es P(s 2 , •) and E(si) < E(s 2 ). 

s 2 strongly simulates si, denoted si A s 2 , iff there exists a strong simulation S 
on S with si<Ss 2 - 

Example 3. Figure 4 illustrates a strong simulation relation on the given IMC. 
We have si A g 2 . The simulation for interactive transitions is obvious. For 
Markovian transitions, note that E(s\) = 2 < E(s 2 ) = 3,P(si,ui) = P(si,zt 2 ) = 
\ = |,P(s 2 ,fi) = | = |,P(s 2 ,U 2 ) = | = |, and the weight function is defined 
by A(u i,ui) = |, A(ui,v 2 ) = ±,A(u 2 ,v 2 ) = §• 

Proposition 2. [7] For any IMC and any state s\,s 2 £ S 

(1) si ~ S 2 implies si A $ 2 . 

(2) A n A -1 coincides with ~. □ 
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Fig. 5. Scenario of weak simulation relation on IMCs 



Definition 7. A preorder S on S is a weak simulation iff for all si<Ss 2 : 



A : S x S — > [0, 1], Si : S — > [0, 1] and sets Ui, Vi C S(i = 1, 2) given by 



such that: 

— U11SS2 for any v\ £ V\ and s\Sv 2 for any V2 £ V2, 

— A(ui,U2) > 0 implies u\ £ U±,U2 £ U2 and u\Su 2 , 

~ K i ' Eu 2 et/ 2 ^(^>“2) = 61 H • P(si,w) and 

K 2 ■ J 2 Ul eU! A(w, u i) = 82(10) ■ P(s' 2 ,w) for all w £ S, and 
- Ki ■ E(s\) k K 2 ■ E(s' 2 ). 
where K t = J2 Ui eUi ' P( s i) u i) f° r * = 1,2. 

S2 weakly simulates si, denoted si ^ s 2, iff there exists a weak simulation S 
on S with siSs 2 . 

Figure 5 gives an intuitive imagination of weak simulation relation. The suc- 
cessor states of weakly similar ones (e.g., si ^ s 2 in the figure) are grouped 
into two subsets according to the function Si, denoted by Ui and V, respectively 
(Note that the sets Ui and V, are not necessarily disjoint). The transitions to 
the ^-states are viewed as “internal” moves and such transitions are taken to- 
tally with probability 1 — A”,;. Accordingly, the transitions to the C/j-states are 
considered as “observable” moves and such transitions are taken totally with 
probability AT,. The Ai-states and A 2 -states are related by a weight function A. 
It is a weight function for the probability distributions Si(-) ■ P (si, -)/Ki. 

Proposition 3. For any IMC and any state si, s 2 £ S 

(1) si A g 2 implies si ^ s 2 . 

(2) ^ fl ^ _1 coincides with m. 




s 2 ; s 2 an d there exist functions 



S2 and s) Ss ' 2 , and 



Ui = {ui £ S | R(s', Ui) > 0 A Si(ui) > 0} and 
Vi = {vi £ S | R(s(, Vi) > 0 A Si(vi) < 1} 



Proof. (1) follows directly from the definitions, where for the strongly similar 
states si and s 2 , their successor states can be considered to be all in set Ui , i.e., 
we can let V) = 0,Si(ui) = 1 and 5 i(vi) = 0 in Definition 7 so that the strong 
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simulation can be viewed as such a special case of weak simulation. To certify 
(2), we see that the coincidence of interactive transition is straightforward, and 
the coincidence of stochastic behaviours has been proved in [7]. □ 

4 Logical Characterizations 

In this section, we investigate logical characterizations of simulation and bisimu- 
lation defined in the previous section. The logic we adopt is a variant of an action- 
based logic termed aCSL (action-based CSL), which is first proposed in [18] to 
characterize stochastic process algebra. The main difference between our logic 
and the logic in [18] is that there is no steady-state probability operator S in 
our logic. This is due to the separation of interactive and Markovian transitions. 
Since the execution of interactive transitions are not confined to the execution 
of Markovian transitions, interactive transitions may destroy the steady-state of 
Markov chains. Therefore, the steady state of IMCs can not be reached if there 
exist interactive transitions. 

4.1 Action-Based CSL 

When a transition is taken from one state in an IMC to another, there are two 
characters to be specified, the time spent in the previous state and the action it 
may interact with. In order to represent both these two characters in a uniform 
way, we use a pair (a,t), where the first component denotes the action and the 
second denotes the time. If the transition is just Markovian transition, i.e. , it 
does not interact with any action, we denote it (*,t). 

Now let Label = ( Act U {*}) x Kfyo and N be the set of natural numbers. 

A path through an IMC is a sequence cr = sq Si — ^ • • • Sfc_i - — > Sk 
with Si £ S,li = ( ai,ti ) £ Label, i £ N such that from s,; to Sj+i there exists an 
interactive transition or Markovian transition. If Sk is absorbing and it cannot 
take any interactive transition, we called it a finite path, otherwise it is called 
an infinite path. We use Path(s) to denote the set of paths in an IMC starting 
from s. 

For infinite path a and i £ N, let a[i] = Si, the ( i + l)-st state of cr, and 
5(a,i) = ti, denoting the time spent in Si. For t £ Ifyo and i the smallest index 
with t < ]Cj=o a @t = c[i], the state in a occupied at time t. For 

finite path cr that ends in Sk, cr[i ] and S(a,i) are only defined for i ^ k. For 

L C Label, we denote cr[i\ cr[i + 1] whenever a[i] can move to cr[i + 1] by 
taking a Markovian or interactive transition specified by the element in L. 

A Borel space constructed on paths is defined as in [6]. Since there are two 
different kinds of transitions in IMCs, the probabilistic measure on path must 
be revised slightly. Let C(sq, Iq, ■■■, Ik- i, Sk) denote the cylinder set consisting of 
all paths cr £ Path(so) such that cr[i ] = sfii < k ) and S(cr,i) £ C < k). 

The probability measure Pr on paths is defined by induction as: 

(1) Pr(C(so)) = 1, 
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(2) For k ^ 0, a € Act 

Pr(C(s 0 , / 0 , ..., h-i, s k , I', s’)) 

= f Pr(C(s 0 ,I 0 , s k )) ■ P (s fe , s') • f r E(s k ) ■ e~ E ( Sk) t dt if s k s', 

\ Pr(C(s 0 ,I 0 ,...,Sk)) if s k > s'. 

The interactive transitions are ignored when computing the probability on paths. 

Syntax. For p € [0,1], cxi€ {<, <, >}, the state-formulae of aCSL are defined 

by the grammar 

<P ::= true \ <P A ^ | ^<1 \ V^ p {p) 

where path-formulae are defined for t € R>o and A, B C Act by 

ip ::= $ A U <t <I> | $>a U < t B ( I’- 

Note that atomic propositions are absent in this logic. The state-formulae 
have the usual meanings as in CSL. The path-formula aH <1 ^ 2 is fulfilled 

by a path if a ^ 2 -state is eventually reached via visiting only #i-states before, 
while interacting only with actions in A; besides, going from the beginning of the 
path until reaching the ^-state should last at most t time units. The formula 
<P± requires in addition that a move to a ^ 2 -state is actually made 

and this transition is labelled by some action in B. The commonly used next 
operator can be derived as follows: 

= true zU^A®- 

Note that in this sense, the concept of “next step” in this logic is based on the 
interactive transition. 



Semantics. Let M = (S,A, — >, — -») be an IMC. The state formulae of aCSL 
are interpreted over the states of an IMC and the path formulae of aCSL are 
interpreted over the path of an IMC. We give aCSL formulae semantics by defin- 
ing the following satisfaction relation |= on states and paths. 



Definition 8. ( Semantics of state formulae) Let Sat{I>) = {s € S' | s |= <P}. 
The satisfaction relation |= for aCSL state formulae is defined by: 



s [= true 
s \= 

s \= A <?2 
S P txSp{.P) 



for all s € S' 
iff s ^ <p 
iff s \= A s |= 
iff Prob(s, p) txi p 



Here 



Prob(s, p) = Pr{a G Path(s) \ a \= p}. 
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Definition 9. ( Semantics of path formulae) Let L* A = (lU {*}) x R^Oi La = 
AxKj-o, and Lb = BxR^o- The satisfaction relation |= for aCSL path formulae 
is defined by: 

a \= <Pi aU <1 ^2 iff 3 k ^ 0. (cr [k] \= L> 2 

A(V0 ^ * < k — l.cr[i] 

Aa[k — 1] |= <Li A <r[k 

AEt'o <K < m)) < * 

a |= L>i AU <tj B ® 2 iff 3 k > 0. (cr[fc] (= <P 2 

A(V0 ^ * < k — l.cr[i] 

Aa[k — 1] \= A a[k 

AEt'o 5 (<m)) < A 

Remark that <5(<r, i) denotes the sojourn time in state <j[i\. Clearly, the path 
formula <Pi AU <t< &2 is valid for a path where its first state (i.e., cr[0]) satisfies 
<L 2 regardless of its next states it will pass through. But for the path formula 
L>i aU <1 b ® 2 we must consider at least one step — the last step must take an 
interactive transition which is labelled with some action in B. 

4.2 Logical Characterization of Bisimulation 

Strong bisimulation for CTMCs has been proved to coincide with CSL- equiva- 
lence [4, 13]. That is, if two states are strongly bisimilar, then they satisfy the 
same CSL formula, and vice versa. For weak bisimulation, [7] has proved that it 
coincides with CSL\x _ eqtiivalence, where CSL\x is the fragment of CSL without 
the next-operator. In this section, we show the similar results of bisimulation for 
IMCs and aCSL. 

We use =l to denote the equivalence for some logic L 1 i.e., si =l s 2 iff 
\/<L> £ L, si |= S 2 |= 

Let aCSL” denote the subset of aCSL where in the path formula L> AU <t B& 
we further restrict that r B. It then corresponds to the logic CSL\x- The 
relation between bisimulation and the logical equivalence in the context of IMCs 
is stated in the following theorem. 

Theorem 1. Let M = (S,A , — be an IMC, and si,S 2 £ S , then 

(1) Si ~ S 2 <=> Si =aCSL s 2 . 

(2) Si « S2 Si —aCSL~ s 2- 

Proof. (1) Similar to [18] and we only give the sketch here. The proof 

starts by an induction on aCSL formula L>. The only non-trivial case is to prove 
the result holds for <L> = "Px p (</>)• Here we only give the proof of the path formula 
<L>i AU Kt B& 2 - The other case is similar and simpler. By defining a set Bf(t) 1 
that denotes the paths starting in s and reaching a <P 2 -sta,te within t time units 



|= <?i A cr[i] a[i + 1]) 
-l)-^a[k) 



\= <Pi A o[i\ <r[i + 1]) 
~l]^a[k) 



1 For the formal definition of B^(t) we refer the reader to [18]. 
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in n steps, where in the first n — 1 steps it may only interact with actions in 
A\B and the last step must interact with some action in B , we can transfer the 
goal of proof to the following 

oo oo 

Vi > 0 ,J2 p r{° e = ^Pr{a £ Pf(f)}, 

2=1 2=1 

which can be proved by induction on n by proving that for all n > 0, 

Pr{aefl?(t)} = Pr{a6B?(t)}. 

The base case is obvious. In the induction phase we have to distinguish two 
cases: 

— Case 1: The first transition is an interactive transition. We have Pr{<7 £ 
^n+i(i)l = PrW G — x)} for u \= <P± and 0 < x < t. Then by Si ~ S 2 
and the outer induction hypothesis that bisimilar states satisfy the same 
aCSL formula we can take the same interactive transitions as si from S 2 
to v within x time units such that v ~ u and have 

Pr{cr £ P* 2 +1 (f)} = Pr{, 7 £ B v n (t - x)} 

= Pr{cr £ P“(t-x)} 

= PrW G B’ViWI- 

— Case 2: The first transition is a Markovian transition. This case is similar 
to [18], and we also have Pr{er £ B^ +1 (t)} = Pr{a £ B^ +1 (t)}. 

We need to show that if si |= $ and S 2 |= ^ for all ^ £ aCSL , 
then si ~ S 2 - This can proceed by induction on aCSL formula. The only non- 
trivial case in the induction phase is that if si \= V((p)As 2 [= P(v J ), then si ~ S 2 . 
Here, again we present the proof of path formula <Pi B& 2 - Using the above 
notation, we have 

Vn > 0, Pr{cr £ B^(t)} = Pr{a £ B s n 2 (t)}. 

If n = 1, a consists of only one P-transition and obviously si ~ S 2 - If n > 1 and 
the first transition of a is an interactive transition, i.e., si and S 2 can both take 
an d-transition to the next state that also satisfies Q\. By induction hypothesis, 
these ^i-states are bisimilar. If, on the other hand, the first transition of a is 
a Markovian transition, we have the similar transformations of Pr{er £ P^ 1 } 
and Pr{cr £ P^ 2 } as in [18]. These yield R(s 1; C) = R(s 2 , C) for any C £ S/ 
Following the definition of strong bisimulation, we get si ~ S 2 - 

(2) Similar to (1), where we ignore the r-actions when considering the interactive 
transitions. □ 

Corollary 1. For any IMC and any state Si, S 2 £ S, 

si —aCSL s 2 implies Si =~CSL s 2- 

□ 
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4.3 Logical Characterization of Simulation 

The logical characterization of simulation relation for Markov chains have been 
studied in [3, 12]. It turns out that simulation preorder weakly preserves a subset 
of CSL formulae, i.e. , the safety (or liveness) formulae of CSL. Weak preserva- 
tion means if si ^ S 2 then for all safety formulae <P it follows that S 2 \= $ 
implies s± \= but the converse does not hold necessarily. Here we show that in 
the context of IMCs and the logic aCSL, the result holds as well. 

aCSL safety and liveness properties. Safety and liveness properties are two kinds 
of important properties. Safety properties assert that something bad never hap- 
pens while liveness properties assert that something good will eventually happen. 
Since the safety and the liveness properties are dual, we only discuss the safety 
properties in the following. As usual, safety properties are negation- free, i.e., they 
are in positive normal form, and the probability bounds are restricted. Formally, 
the syntax of aCSL-safety formulae is defined as: 

$ ::= true \ false | A <P \ $ V 4> | V A U <1 s -4>) | V A U <1 -.#) . 

For example, a safety aCSL formula V<^o.ai(true{R un }U <wo false) expresses that 
the probability of which the system will down within 100 time units is at most 
0 . 01 . 

We use in the following =4l to denote the weak preservation for some logic L , 
i.e., si s 2 iff £ L, s 2 \= $ => Si |= $. 

Now, let aCSLg denote the aCSL-safety formulae, and aCSL^ denote the 
subset of aCSL-safety formulae where we further restrict that r ^ B in the path 
formulae AU <t b&- The following theorem shows the weak preservation results 
of simulation preorder on IMCs. 

Theorem 2. Let M = (S,A, — »,--->) be an IMC, and si,S 2 £ S, then 

(1) Sl S 2 => Sl =4aCSL s s 2 - 

(2) si ^ s 2 => si S 2 - 

Proof. The core of the proof is to show that if si A S2 ( Sl ^ s 2 ) then Probes i, ip) 
^ Prob(s 2 ,<p) for all aCSLg (aCSLg) path formula ip. The result for CTMCs 
and CSL has been proved in [3]. We can adopt this result, following the same 
treatment of interactive transitions as we did in Theorem 1 and then get the 
result as required. □ 

Corollary 2. For any IMC and any state Si, S 2 £ S: 



si =4aCSL s S2 implies Si 4 aC SL- s 2 - 



□ 
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Fig. 6. Branching time relations for IMCs 



5 Conclusions 

In this paper we investigated the branching time equivalences for IMCs, a power- 
ful model of performance evaluation. We focused on simulation and bisimulation 
relations, and studied how to lift these concepts from classical labelled transition 
systems and pure stochastic settings to IMCs. Our notions of various branching 
time relations are rather natural extensions of those on both labelled transition 
systems and stochastic settings. It is clear that such extensions to labelled tran- 
sition systems and stochastic settings are orthogonal to each other. Therefore, 
our equivalent and preorder relations are compatible with the existing ones. 

We also studied the logical characterizations of the branching time relations. 
The logic we use to characterize IMCs is the action-based logic aCSL. The results 
presented here subsume those correspond to the CTMCs and the logic CSL. This 
is not surprising because of the compatibility of our branching time relations on 
IMCs and those on CTMCs. 

To summarize, we depict the interrelation of the branching time equivalences 
and preorders in Fig. 6, where R — > R' means that relation R implies rela- 
tion R' . 

The results shown in this figure can be seen as a complement of those given 
in [7], where a branching time spectrum for DTMCs and CTMCs is presented. 
As mentioned in the introduction, bisimulation and simulation relations can be 
used to solve the state space explosion problem to a large extent. Such problem 
is the main obstacle of model checking approach in practice. Our future work 
is to investigate model checking of IMCs against aCSL. These branching time 
equivalences and preorders can be used to efficiently aggregate the state space 
of IMCs and to simplify the procedure of model checking. 
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Abstract. This paper concerns discrete-time queueing systems operat- 
ing with a first-come-hrst-served (FCFS) queueing discipline. Customers 
arrive in the system according to a renewal process; the inter-arrival 
times form a family of independent and identically distributed (i.i.d.) 
random variables. We establish a relationship between the probability 
generating function (pgf) of the system delay of an arbitrary customer 
and the pgf of the system contents during an arbitrary slot. Based on 
this result we derive relationships between the mean and variance, the 
mass function and the tail probabilities of the respective distributions. 
These relationships are valid irrespective of the characteristics of the ser- 
vicing process, i.e., irrespective the number of servers, the distribution 
of the service times and possible correlation between the service times of 
consecutive customers. 



1 Introduction 

Queueing occurs in many nodes of communication networks and in many IT- 
elements. Buffers are typically introduced where multiple data streams, appli- 
cations or connections make use of common resources. Examples of such are 
communication links and computational resources. Queueing is especially abun- 
dant in packet-oriented networks such as the Internet. When resources are shared 
between a large number of applications, and packets streams are multiplexed, 
those resources are used more efficiently. However, sharing comes at the expense 
of the resource not permanently being available to arriving or new user; some 
of them will have to wait because the resource is busy and hence experience 
a delay. With the advent and growing popularity of delay-sensitive services (e.g. 
multi-media services) over the World Wide Web, tight control over the delay 
has become more important than it was when the Internet was predominantly 
providing services such as e-mail and browsing of static content. 

* TELIN: Telecommunications and Information Processing 

** SMACS: Stochastic Modeling and Analysis of Communication Systems 
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Queueing processes are typically studied from two perspectives: that of the 
user (or customer) and that of the provider. The user’s primary concern lies 
with the delay that he or she experiences. IN a communication setting: how much 
delay and delay variation can the application tolerate and how much delay should 
the receiving end expect and be prepared to accept? The primary concern for 
the provider lies with the queue contents - for instance, how much buffer space 
should she provide such that the probability of packet loss is sufficiently small. 
The buffer space itself may be a resource that is shared by multiple queues. 
In this paper we derive a relationship the delay experienced by an arbitrary 
customer and the number of customers present during an arbitrary time slot. 
We assume renewal arrivals and a first-come-first-served queueing discipline. 

Little’s Theorem [1, 2, 3, 4] is probably the best-known result of queueing the- 
ory. It relates the first-order moment of the system contents during an arbitrary 
slot to the first moment of the system delay of an arbitrary customer. The rela- 
tionship holds regardless of the nature of the arrival and servicing/departure 
process. Where authors have generalized the result to higher-moments they 
have imposed restrictions on either the arrival process or the servicing process. 
Marschal [5] obtained a relationship between the moments of the waiting time 
and the queue contents for continuous-time multi-server queueing systems op- 
erating with a FCFS queueing discipline, Poisson arrivals and general service 
times (i.e. , M/G/c ). Brumelle [6] derived expressions for the moments of the 
queue contents for the more general G/G/c queueing system but not explic- 
itly in terms of moments of the waiting-time distribution. Tight relationships 
between the probability mass functions (pmf’s) of the system delay (of an ar- 
bitrary customer) and the system contents (during an arbitrary slot) have been 
derived for discrete-time queueing systems with service times of 1 slot, both for 
the single-server case [7] and for the multi-server case [8] . A similar relationship 
between the probability generating functions (pgf’s) was derived recently for 
the multi-server queueing system with geometric service times [9]. This paper 
establishes a formula that allows to derive the pgf of the system contents from 
the pgf of the system delay. We assume a renewal arrival process, i.e., whereby 
the interarrival times are independent and identically distributed (i.i.d.) random 
variables. 

The relationships established in this paper are restricted to renewal arrivals, 
but allow a wide range of servicing processes. Note however, that in order to 
apply the result, it must first be possible to obtain the pgf of the system delay of 
an arbitrary customer. The result can be applied on the queue, the servers or on 
the queue and the servers taken together. It does require however that customers 
depart from the system in the order of their arrival. Hence, the relationship is 
valid for the queue of a multi-server queues with i.i.d. service times, but not for 
the system (i.e., queue and servers) when the service times are non-deterministic. 
The proof does not require that a limiting (i.e., steady-state) distribution of 
system delay and system contents exist. The system contents, for instance, does 
not have a limiting distribution when the arrival process is periodical, i.e., when 
the interarrival times are always a multiple of a period that consists of more than 
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one slot. The system delay, for instance, does not have a limiting distribution 
when customers are always served in n-tuples (e.g., pairs, trios, etc.). However, 
in both cases the system contents (during an arbitrary slot) and the system delay 
(of an arbitrary customer) remain well-defined; and the relationships derived here 
apply between their respective pgf’s. However, in the event that the steady-state 
distributions exist (and usually they do), they are identical to the distributions 
for arbitrary slots or arbitrary customers. 

The paper is organized as follows. In Sect. 2 we introduce our numerical 
example. We return to this numerical example after having derived our main re- 
sult. Section 3 introduces the notation and Section 4 introduces further auxiliary 
variables and presents intermediate results. Those are used in the next section, 
in which we derive the main result of the paper in integral form. The next two 
sections then, are spent on two important special cases: in Sect. 6 the case of 
the system delay having a rational pgf and in Sect. 7 the case of the interar- 
rival times having a rational pgf. Finally, in Sect. 8 we return to our numerical 
example and show how the result obtained in the paper can be applied on the 
numerical case. Finally we write conclusions and make suggestions for further 
research. 



2 Application: Problem Setting 



We consider the provider of a digital communication link that can transmit one 
data unit per time slot. Messages arrive according to a very regular pattern: 
every c time slots she receives c messages. The number of cells in a message, i.e. , 
the message length is a stochastic variable. All message lengths are i.i.d. random 
variables with a Poisson distribution with parameter p, 0 < p < 1. The provider 
will queue the message in a buffer in front of the communication link. The 
queueing system is a single-server queue with deterministic interarrival times 
(of c slots) and service times (per message) with B(z) = exp (cp(z — 1)). For 
this type of queueing system the system delay of an arbitrary customer has been 
derived in [10] and is given by: 



D{z) = 



c(l - P) (z - 1) B(z) P(z) 
z c - B(z) 



C — 1 



with P(z) = J 



1 - 



(1) 



whereby {cf> n \ n = 1, . . . , c— 1} are the c— 1 distinct zeros of the denominator z c — 
B(z) inside and on the unit circle and not equal to 1. We now derive a result 
that allows to derive the pgf of the queue length from (1). We return to this 
numerical example in Sect. 8. 



3 Model 

We consider a discrete-time queueing system operating with a FCFS queue- 
ing discipline. Time is divided in fixed-length (time) slots separated by clock 
instants t, Vf £ IN. 
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The customers arrive on clock instants according to a renewal process. Let a n 
denote the arrival instant of the n-th customer and let A n = a n + 1 — a n , Vn £ 
INo, denote the n-th interarrival time. The interarrival times are i.i.d. random 
variables with common pmf {a(k) = Pr [A t = k\,k £ IN}, corresponding pgf 
{A(z) = Efz" 4 ™] , |z| < TZa} and expected value E[A n ] = 1/A. We assume that 
7 Za is strictly larger than 1. 

Let d n , Vn £ INo, denote the departure instant of the n-th customer. We 
require that customers depart from the system in the order of their arrival. 
Let t n = max{d ra _.i, a n } denote the start of the service time of the n-th customer. 
Then B n = d n — t n , Vn £ INo, denotes the service time of the n-th customer 
(this service time may assume the value zero for some customers if more than 
one customer departs at the same clock instant) . Let M n denote the sum of the 
service times of the first n customers, i.e. , M n = B\ + B 2 + ■ ■ ■ B n . We assume 
that the limits a = lim^^oo n/M n exists with probability 1 and that A < a. The 
load p is defined as A/er and therefore equals the limit p = lim^^oo M n /a n and 
satisfies p < 1. 

Let [/*, Vf £ INo, denote the system contents, i.e., the number of customers 
present, during the slot (t — 1, t]. We assume, without loss of generality, that we 
start with an empty system, i.e., that U\ = 0. We define the pmf {u(k), k £ IN} 
and pgf {U(z),\z\ < 7 Zu} of the system contents during an arbitrary slot as 

T T 

u{k) = ^lim^ - J2 Pr ^ = and U f J2 E ' ( 2 ) 

We assume that 7 Zu is strictly larger than 1. From the above definitions it 
follows that U (0) = 1 — p. The system delay D n = d n — a n , Vn £ INo, refers to 
the number of slots that the n-th customer spends in the system. We define the 
pmf {d(k),k £ IN} and pgf {D(z), \z\ < 7 Zd} of the system delay of an arbitrary 
customer as 

N N 

d(k) = lim — y^Pr[7A„ = fc] and D(z)= lim — y^Erz Dn l . (3) 

V ’ N — >oo N ^ TV— >00 N ^ 1 J 

n = 1 n = 1 

4 Preliminary Results 

We introduce the following auxiliary variables: the waiting time of a customer, 
the idle time following the servicing of a customer, and the virtual waiting time 
at a clock instant following a busy slot. We prove three lemma’s that we will use 
to derive the main result in Sect. 5. 

Let W n = t n — a n , Vn £ INo, denote the waiting time of the n-th customer. 
We have that W\ = 0 and for Vn > 2: W n = max{7A„_i — 4 ra _i, 0}. We define 
the pmf {w(k),k £ IN} and pgf {W(z),\z\ < IZw} of the waiting time of an 
arbitrary customer in the same way as the pmf and the pgf of the system delay 
were defined via (3). Note that Vn £ INo: W n < D n and hence that for Vx £ 
(0,7 ^d): E[i h/ “] < Efx 15 ”]. After averaging over all customers this yields that 
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Vx £ (0,7 £d): W(x) < D(x) and hence that W(z) converges on the open interval 
(0,7?.£>). Hence, 7 Zjj < IZw- 

Let I n denote the idle time after servicing the n-th customer, i.e., I n = 
max{A n — D n , 0}. Note that if W n+ \ > 0 then I n = 0. Let I(z) denote the pgf of 
the idle time before servicing an arbitrary customer arriving in an idle system, 
i.e., 

1 N 

I(z) = lim - £ E [z 1 ” I W n+ 1 = 0] . (4) 

iv — >-oo iv — 
n— 1 

Note that Vi € 1N 0 : I n < A n and hence that analogously IZi > 7 Za- 
Lemma 1. If z € C and IZfj < |^| < 7 Zd then 

W{z) = D{z)A{l/z)+w{G)\\-I{l/z)\ . (5) 

Proof. The nature of the servicing process yields that W\ = 0 and Vn £ INq : 
W n +i = max{D n — A ra ,0}. After ^-transformation and averaging over all cus- 
tomers this yields 



W(z) = lim 1 ( 1 + V E[1 (W n+ 1 > 0) z D "~ A " + 1 (W n+ i = 0)] ] 

N — >-oo iv \ z — / 

\ n= 1 / 

i w 

= J im M ^\. zDn An + 1 ( W "+ 1 = °) I 1 - - 7 "]] ■ 

iv— >■ oo iv z ' 

n— 1 

In view of the definitions of the pgf D(z), W(z) and I(z) and the statistical 
independence of D n and A n this yields (5). The condition IZ^ 1 < \z\ ensures 
that the power series of A(\/z) and /(I/ 2 ) converge. Likewise, the condition 
\z\ < 7 Zd follows from the requirement that the power series of W(z) and D(z) 
converge. □ 

Let b m , Vm £ 1N 0 , denote the end of the m-th busy slot. Let c m , Vm £ 1N 0 , 
denote the customer present during (b m — 1, b m ) having the smallest index, i.e., 
let c m = min{n £ INo | a n < b m < d n }. Let V m = b m — a Cm , Vm £ INo, denote 
the time spent by customer c m in the system at clock instant b m . We refer to V m 
as the virtual waiting time at clock instant b m . We define the pmf and pgf of the 
virtual waiting time at the end of an arbitrary busy slot as 

M M 

v(k) = lim — Pr \V m = k] and V(z) = lim — y^E| 2 ym l . (6) 

V ’ M—>oo M ^ L J W M—*oo M L J V ; 



Lemma 2. If z £ C and \z\ < IZd then 



V{z) 



D(z) - W(z) 



z- 1 



( 7 ) 
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Proof. Where V(z) converges, then also any subrow of (6) converges. Those 
subrows then each have the same limit value as the row in (6). We consider the 
subrow that consists of only those clock instants following busy slots that are 
departure instants. Hence, 



V(z) 



lim 

N — »oo 



l 

m n 



Mjv 

X>[* Vra ] 



m — 1 



lim 

N — »oo 



N 

M n 



N B n 



lim — 

N — »oo N 



EE4 

n— 1 m— 1 



VM n _ 1 +m 



The first factor converges to a. Note that D n = W n + B n , Vn £ INo, and hence, 
that the virtual waiting times at clock instants in the interval (t n ,d n \ are given 
by W n + 1, W n + 2, . . . , and W n + B n = D n . This yields for the pgf of the virtual 
waiting time at the end of an arbitrary busy slot: 



<7 



lim 

N — >oo 



l 

N 



n= 1 



i N 

z D "1 = CT lim — Ve 

N — KX> N ‘ ^ 
n— 1 



gD n -\- 1 g\V n -\-l ~ 



Z-l 



which in view of the definitions of W(z) and D(z) yields (7). Note that V(z) 
converges where both D(z) and W(z) converge. In view of TZd < P-w it follows 
that 77 _d is the radius of convergence of V(z). □ 

Lemma 3. If z € C and \z\ < TZu, with 7 Zfj 1 = AiflZfj 1 ), then 

^)-i p L jc no-i 

z-l 2nif c C(C- 1 )[ 1 -^( 1 /C)] ’ u 

with C being a contour around the origin such that £ C: |£| < 7 Zd and 

M( i/C)l <i- 

Proof. The system contents during the m-th busy slot exceeds k if and only 
if the virtual waiting time at clock instant b m exceeds the sum of the first k 
interarrival times following the arrival of the customer c m . This yields, Vfc £ IN: 



Ubm P k ^ V m > A Crn T • • • T A Cm+k _i , 



which yields 

oo oo l — l 

^2 Pr [ Ub m = S \ = Xm Pr = ^ Pr H + A Cm+k- 1 = r] . (9) 

s=k-\-l 1=1 r— 0 

The interarrival times {A n ,n £ INo} are a family of i.i.d. random variables. 
Hence, the pgf of A Cm + A Cm+1 + • • • + A Cm+k - i is given by A(z) k . We write the 
last factor as a complex integral along a contour (i.e. , a closed curve) around the 
origin (cf. [11]), Vk £ IN: 

Pr [H Cm + • • • + = r] = ^7 <f d£ A^) k C^ 1 , 
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with i being the imaginary unit and L being a contour around the origin such 
that V£ £ L: |£| < TZ a- After a change of integration variable from £ to £ = l/£, 
and integration along C, the image of L after inversion, this yields: 

Pr [A Ct + • • • + A ct+fc _! = r] = -WdC A{ l/Q k C~ X , 

j c 

with C being a contour around the origin such that V£ £ C: IZ^ 1 < |£|. Substi- 
tuting the latter result in (9) and averaging over all busy slots yields: 



1 

P 



OO 



oo l—l 



= 

s=k+ 1 1=1 r = 0 



j> d( v{l)A{l/Q k C~ l • 

J c 



Note that we have used that u{ 0) = 1 — p. Multiplying both sides by p and z k 
and summing over k from 0 to oo yields 

OO OO OO OO l—l p 

A u {s)z k = f M(vc)] fc c r_1 • 

fe=0s=fe+l fco 1=1 r=0 Z • ,C 

The left-hand side evaluates to [U(z) — 1 }/{z — 1) for \z\ < 7 Zjj, whereby IZu re- 
mains to be determined. On the right-hand side, the summations can be brought 
behind the integral if the contour C is properly chosen. Convergence of the infi- 
nite summations over k and l require that Vf £ C: |zA(l/£)| < 1 and |£| < 7 Zd- 
The condition \zA{l/C)\ < 1 imposes an upper-bound for |A(1/£)| and hence 
a lower bound on |£| that depends on z and the argument of £. This lower 
bound is most severe along the positive real axis. A proper contour C can be 
constructed if and only if \z\ < 1/A(1Z~^). Hence, 1Z fj 1 = A(1Z~j^). If \z\ < 7 Zu 
the summations converge and after rearranging factors the expression reduces 
to (8). □ 



5 Integral Forms 



Using the lemma’s we derive a relationship between the pgf of the system con- 
tents during an arbitrary slot and the pgf of the system delay of an arbitrary 
customer. We verify that our findings are in agreement with Little’s Theorem 
and establish an integral form for the variance of the system contents during an 
arbitrary slot. 

Theorem 1. If z £ C and \z\ < IZu, with TZfj 1 = A(TZ} 7, 1 ), then 



UW - 1 = A l At ^(0 [1 - -4(1/0] 

Z-l 27Ti f c AC-1) 2 [1-^(1/C)] ’ 



(10) 



with C being a contour around the origin such that V£ £ C: 1 < |£| < 7 Zd and 
\zA(l/C)\<l. 
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Proof. Substituting the result of Lem. 2 in the result of Lem. 3 and eliminating 
W(Cf) using the result of Lem. 1 yields, for \z\ < 7 Zu- 

U{z) - 1 = A iA C D { 0 [1 - A(1/Q] - w(0) C [1 - /(1/Q] - (C - 1)/«T 
z-1 2m C(C-1) 2 [1-^(1/C)] 

with C being a contour around the origin such that \/f £ C: P^ 1 < |C| < Pd 
and \zA{l/Cf)\ < 1. Note that ( = 1 is not a pole (or otherwise a singularity) 
of the integrand of (8). Hence, it is not a singularity of the integrand in the 
expression above. The right-hand side can be split in two terms: 

A l lr ^(0 [1 - A(l/p] _ r w( 0) [1-/(1/Q] + (l-l/0/a 

2mf c ^ (C-l) 2 [l-*A(l/0] 27ri JA (C - l) 2 [1 - zA(l/Q\ 

The integrands of both terms have a pole at ( = 1. We choose the contour C 
such that this pole lies inside C by imposing that VC £ C: 1 < |C|- This choice 
is possible regardless of the value of z. We now change the integration variable 
in the second term, replacing C by £ = 1/C, and integrating along a contour L 
which is the image after inversion of C . The last term then becomes: 

_ A Lf w{0) [i-^(0] + (i-o/q- 

2ni JA (£- l) 2 [l-zA($] ’ 

with L being a contour around the origin such that \/f £ L: TZf, 1 < |£| < 1 
and |zH(C)| < 1. Since |C| < 1 along and inside L, the functions 1(f) and H(£) 
remain analytical inside and on L and the pole £ = 1 lies outside L. Along L, 
the condition \z A(£)| < 1 holds. This implies, by the Theorem of Rouche [12, p. 
123], with /(£) = 1 and g(f) = z A(f), that 1 — z A(£) has no zeros inside and 
on L. The integrand of the last term is therefore an analytical function inside 
and on L. An application of Cauchy’s Residue Theorem [12, p. 120] then yields 
that the second term is zero. Hence, U(z) is given by the first term only of the 
last expression, i.e., by (10). □ 



Using the moment-generating property of pgf’s allows deriving expressions 
for the moments of the distribution of the system contents during an arbitrary 
slot by evaluating the derivatives after z of U(z) at z = 1. 

Corollary 1 (Little’s Theorem). There holds E[t7] = A E[U]. 

Proof. Evaluating both sides of (10) at z = 1 yields 



U'( 1) 




D(0 

(C-1) 2 



XD'(1) . 



On the left-hand side we used de l’Hopital’s Rule; on the right-hand side we used 
Cauchy’s Residue Theorem. □ 



Corollary 2. There holds 



var[t/] + E [U] 2 



A l At ^(0 [1 + A/Q] 
2m J c ^ (C - l) 2 [1 - AL(1/C)] 



( 11 ) 



with C being a contour around the origin such that VC £ C: 1 < |C| < P-d- 
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Proof. Evaluating (10) and its first derivative after z at z = 1 and using U"( 1) + 
U'{1) = var[I7] + E[f7] 2 immediately yields (11). □ 

The expressions in the right-hand side of (10) and (11) are in the form of a 
contour integral with D(z ) appearing in the integrand. Those expressions can be 
evaluated by means of numerical methods, see for instance [13]. Alternatively, 
and when possible more conveniently, the expressions can be converted to alge- 
braic expressions with the help of Cauchy’s Residue Theorem. This is the case 
when either D(z) or A(z) is a rational function. In Sect. 6 we discuss the special 
case of rational D(z); in Sect. 7 we discuss the special case of A(z) being rational. 



6 System Delay with Rational PGF 



In this section we consider the case where the pgf D(z) of the system delay 
during an arbitrary slot is rational and only has simple poles. Since D(z) is the 
pgf of a non-negative random variable, all poles of D(l/z) lie inside the unit 
circle. Let {p n | n— 1, . . . , d} denote the d distinct poles of D(l/z). The partial 
fraction expansion of D(l/z) then reads 



m M = (m) 

n—1 

The poles p, n are either real or occur in complex conjugate pairs. If p n and p, n > 
are each other’s complex conjugate, then necessarily also /\_o(n) and Kjo(n'), 
are each other’s complex conjugate. 

Theorem 2. If D(z) is rational and D{\/z) has partial fraction expansion (12) 
then also U{z) is rational and U(l/z) has partial fraction expansion 



N 

U{l/z) = 1 - P+Yl 

n—1 



Kjj(n) 
z- 0 n 



(13) 



with Vn = 1, . . . , d: 



0 n = A(n n ) and K v {n) = A ( j \ K D (n ) (14) 

V 1 — h’n / 

Proof. In view of 1/(0) = 1 — p , substitution of z = 0 in the result of Theorem 1 
yields 

Subtracting both sides of this equation from both sides of (10) yields 



U(z) = 1 - p 




D(C) [1-A(1/Q] 2 
(C-1) 2 [1-*A(1/C)] 
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with C being a contour around the origin such that VC £ C: 1 < |C| < Pd and 
\zA(l/Cf)\ < 1. Substituting 1 jz for z, changing the integration variable from 
C to C = 1/C and then integrating along a contour L which is the image after 
inversion of the contour C yields: 



U{l/z) = l- p+ — 




D( I/O [1~^)] 2 
(i-0 2 [«-^(0] ’ 



with L being a contour around the origin such that VC € L: Tlf^ < |£| < 1 and 
|A(C)| < \z\. The condition |C| < 1 yields that A(C) remains analytical inside L 
and that C = 1 lies outside L. The condition |A(C)| < \z\ yields, by the Theorem 
of Rouche, that the factor 2 — A(C) has no zeros inside L. The condition Tip 1 < |C| 
yields that all poles of £>(1/C) lie inside L. Substitution of (12) then yields: 



U(l/z)=l-p+Y / Idti 

71=1 JL 



Kn(n) [l-A(C)] 2 
(£-/*n)(l-0 2 [*-^(0] ' 



An application of Cauchy’s Residue Theorem then yields (13). 



□ 



Corollary 3. If D(z) is rational and D(l/z ) has partial fraction expansion (12) 
then also 



var [U] + E \U} 2 



x Hfl(fi) [1 + A(/x n )] 

^(M71-1) 2 [1 -A(m„)] • 



(15) 



Proof. Changing the integration variable in (11) in Cor. 2 from C to £ 
yields 



var [17] + E [U] 2 



£>(1/Q [1 + A(Q] 
27Ti J L M c - l) 2 [1 - A(0] 



VC 



with L being a contour around the origin such that VC £ L : 7 If, 1 < |C| < 1. The 
only singularities inside L are the poles of D(l/C). Substitution of (12) in this 
equation yields 



var [17] + E[Z7]‘ 



= E — 

< ^ 9/7T1 



df 



K D (n) [1 + A(Q] 

(C dn) (C l) 2 [1 71(C)] 



An application of Cauchy’s Residue Theorem then yields (15). 



□ 



7 Interarrival Times with Rational PGF 

In this section we consider the case where the pgf A(z) of the interarrival times 
is rational. If the pgf A(z) is a rational function, we define the unique mutually 
prime polynomial functions Pa(z) and Qa(z) such that 

A{l/z) = ^ A \ Z \ , gc&{P A {z),Q A (z)} = 1 and Q j 4 (1) = P j4 (l) = 1 - (16) 
Qa(z) 

Let c = deg Qa- From lim-^oo A{l/z) = a(0) £ [0, 1) it follows that deg Pa < 
deg Qa- 
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Theorem 3. If A(z) is rational and the characteristic function Qa(C)~ z Pa(C) 
has c distinct simple zeros { 7 n (z) | n = 1 , . . . c} for some z £ (D then 



T j( ) = A v- D{l n{z)) ( (z - l)7n(g) \ 2 

^A'il/Uz)) [zl 7 n (z)-l]J ■ 

Proof. Substitution of (16) in (10) of Theorem 1 yields 

U(z) - 1 = A l a C D ^) [Qa(Q - Pa(Q] 
z-1 27ri Jc ^ (C - l) 2 [Qa(C) - 2 *U(C)] 



(17) 



(18) 



with C being a contour around the origin such that £ C: 1 < |£| < 7 Zd 
and \zA(l/Q\ < 1. The condition |£| < Up implies that D ( £) is an analytical 
function inside C. The condition 1 < |£| yields that ( = 1 lies inside C. Unless 
z = 1 , the numerator of the integrand has a simple zero and the denominator 
has a double zero at £ = 1. Hence, unless z — 1, the integrand has a simple 
pole at £ = 1. The contribution to the right-hand-side from the residue of the 
integrand at ( = 1 equals — 1 /(z — 1). The condition \zA{l/(f)\ < 1 yields, after 
multiplication by |Qa(C)I> that £ C: |z P a (C) i < |Qa(C)I- Note that Qa(0 
has c zeros inside the unit circle (counting with multiplicity), and hence also 
inside C. This implies, by the Theorem of Rouche, with /(£) = Qa{() and 
5 (C) = z Pa(() that the characteristic function Qa( 0 ~ z Pa( C) has c zeros 
(counting with multiplicity) inside C. Note that since deg Qa = c and deg Pa < 
deg Qa those are the only zeros of the characteristic function. An application of 
Cauchy’s Residue Theorem and some algebraic re-arranging then yields (17). □ 



Note that (17) still contain the zeros of the characteristic function and those 
depend on z. For general distributions of the interarrival time it is not possible 
to derive a closed- form expression for the "f n (z). Nor is it so that the 7 n (z) are 
necessarily rational functions. 



Corollary 4. If A(z) is rational and the polynomial function Qa(C) — Pa( C) 
has c — 1 distinct simple zeros {/3 n \ n = 1, . . . , c — 1} inside or on the unit circle 
and not equal to 1 then 



c — 1 



A] =2A£- 



D(J3 n) 



-A 7 ( I/#,) \0n~l 



Pn 



A 3 



A 4 



+A 2 var[P] + A 3 E[D] var[A] — — skew[A] + — var[A] + 

o z 

Proof. Substitution of (16) in (11) in Cor. 2 yields that 

D( 0 [Qa(0 + Pa(0] 



var [U] + E [U] 2 = / df 

27T1 JC 



(C-1) 2 [Qa(C)-^(C)] 



1 - A 2 



(19) 



with C being a contour around the origin that fulfills £ C: 1 < |(| <TZd- The 
condition that 1 < |CI along C implies that along C holds |A( 1 /£)| < 1 and hence 
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that |Pa(C)I < |Qa(C)I- An application of the Theorem of Rouche with /(£) = 
Qa{ C) and g( C) = Pa(0 then yields that the polynomial function Qa(() — Pa{0 
has c zeros (counting with multiplicity) inside C. Note that since C can be chosen 
arbitrarily close to (but larger than) the unit circle, those zeros lie inside or on 
the unit circle. One of those zeros is a simple zero at £ = 1, which is a third-order 
pole of the integrand. The contribution of this third-order pole to the right-hand 
side of the previous expression is given by 

A 2 var[D] + A 3 E [D\ var[A] — E skew [A] + E- var[A ] 2 + ^ . 

O Z D 

An application of the Residue Theorem and Little’s Theorem yields (19). □ 



8 Application: Result 



We now return to the application introduced in Sect. 8 and apply the general 
result of Theorem 3. Deterministic interarrival times of c slots correspond with 
the special case A(z) = z c with c £ 1N 0 and A = 1/c. After substituting £ c 
for z, the characteristic function becomes £ c — z c . For z ^ 0 this function has c 
distinct zeros {7 n (z c ) | n = 0, . . . , c — 1} with 7 n (z c ) = a n z and a = exp(27ri/c). 
An application of Theorem 3 for this special case then yields 



U{z c ) 



C 1 

CL 



D(a n z) 



r. 2 

n=0 



l-z c 
1 — a n z 



(20) 



Substitution of (1) thus yields the expression for the pgf of the system contents. 
The variance of the system content is then given by (in view of Cor. 4): 



var[[7] 



var[D] + 



c 2 -l 
6 c 2 



2 



E 



D{a n ) 

| a n - 1| 2 



(21) 



We study the behavior of expected value and standard deviation of the system 
contents (in terms of cells) during an arbitrary slot as a function of the load, 
for the cases whereby the message size c = 1, 2, 4, 8 and 16. Figure 1 shows 
the expected value of the number of cells present during an arbitrary slot as 
a function of the load. The figure shows that as the expected value of the system 
contents increases with the load and with the message size. Figure 2 shows that 
also the standard deviation of the system contents grows with the message size. 
These results show that for this queueing model reducing the message size (and 
the interarrival time) reduces both the expected value and the standard deviation 
of the system contents. 

For this particular example with deterministic interarrival times it is possible 
to conduct explicitly the inverse ^-transformation of (20). This yields a relation- 
ship between the pmf of the system delay and the pmf of the system contents. 
Equation (20) is equivalent to 



U(z c ) 



, c— 1 00 c— 1 c— 1 

~ E E E E z k+i - m a n ^ +i - m) , 

^ n — 0 k — 0 1=0 m = 0 
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Fig. 1. System Contents, Expected Value 




Fig. 2. System Contents, Standard Deviation 



which in view of = c 1 (n is a mutliple of c) reduces to, Vfc € IN: 



u(k) 



^ d ( ck + l ~ m ) 

1=0 m = 0 



y J ^ d (° k + o > 

/=— c+l 



( 22 ) 



whereby d(/c) = 0 for negative values of k. We observe that u(k) is a weighted 
average of the u(k) in the immediate neighborhood of u{ck). The result obtained 
here is similar to the result obtained in [8] in which a relationship between the 
pmf of the system contents and of the system delay was established without first 
establishing a relationship between the pgf, for multi-server queueing system 
with deterministic service times of 1 slot. 
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9 Conclusion 

The paper extends Little’s relationship between the first moment of sojourn 
time and queue contents to a relationship between the pgf of those performance 
measures, for the case of renewal arrivals and FCFS-scheduling. Algebraic ex- 
pressions are obtained when either the interarrival times or the system delay 
have a rational pgf. From that expression a similar expression for the variance is 
derived; in a similar manner such relationships may be derived for higher-order 
moments. Further research might focus on establishing similar relationships for 
more complicated arrival processes. Alternatively, one could focus on estimates 
for the higher-order central moments of the system contents, given (estimates 
of) some central moments and some characteristics of the system delay and the 
distribution of the interarrival times, but not the entire pgf of the system delay. 
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Abstract. In this paper, we consider a discrete-time GI-D-c queueing 
system with general independent arrivals, deterministic service times of 
arbitrary length, multiple servers, an infinite buffer size and a first-come- 
first-served queueing discipline. A relationship between the probability 
distributions of the system contents and the packet delay is established. 
By means of this relation, an explicit expression for the generating func- 
tion of the packet delay is obtained from the known generating function 
of the system contents, derived in previous work. In addition, some im- 
portant characteristics of the packet delay, namely the mean, the vari- 
ance and the tail distribution of the packet delay, are derived through 
some mathematical manipulations. Numerical examples are presented to 
illustrate the analysis. 



1 Introduction 

Discrete-time queueing models play an important role in the performance eval- 
uation of packet-based telecommunication networks, where buffers are used for 
the temporary storage of information packets which cannot be transmitted to 
their destination immediately. In discrete-time queueing models, the time axis is 
divided into fixed- length intervals, referred to as slots, and the service (transmis- 
sion) of packets can start or end at slot boundaries only. The latter implies that 
the service times of the packets consist of an integer number of slots. Usually, 
the performance of a queueing system is expressed in terms of such quantities 
as the system contents (i.e., the total number of packets present in the queueing 
system) and the delay of a packet (i.e., the time (in slots) spent by a packet in the 
system) . Many results have been obtained for the analysis of both quantities in 
a single-server environment. In case systems with multiple servers are considered, 
fewer results are available. Most studies of multiserver systems assume constant 
service times equal to one slot, see for instance [1] and [2]. Multiserver systems 
with geometrically distributed service times have been considered in [3]- [6]. In [7 
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and [8] , discrete-time queueing models with multiple servers and constant service 
times of multiple slots have been studied, but only results in connection with 
the system contents have been derived. 

In the present paper, we will extend the analysis of [7] in order to investigate 
the delay characteristics. A relationship between the distributions of the packet 
delay and the system contents is established first. Then, from the results for the 
system contents derived in [7], the probability generating function (pgf) of the 
packet delay is obtained. Finally, from this pgf the delay-related characteristics, 
i.e., the mean delay, the variance of the delay and the probability that the delay 
exceeds a given threshold, are calculated. To the best of the authors’ knowledge, 
no such study has been reported before. 

The paper is organized as follows. In Sect. 2, we describe the class of discrete- 
time queueing systems under study and introduce some notations. Some results 
of [7], which will be used in the paper, are also summarized there. For the 
considered class of queueing systems, we establish a relationship between the 
steady-state pgf’s of the system contents and the packet delay in Sect. 3. In 
Sect. 4, the performance measures for the packet delay are presented. In Sect. 5, 
some numerical examples are given to illustrate the analysis. Finally, the paper 
is concluded in Sect. 6. 

2 System Description, Notations and Preliminary Results 

We consider a discrete-time multiserver queueing system with c (c > 1) servers 
(output channels). Time is divided into fixed-length slots. Packets arrive at the 
input of the system according to a general independent arrival process, i.e., 
the numbers of packet arrivals during the consecutive slots are assumed to be 
independent and identically distributed (i.i.d.) random variables; we denote their 
common pgf by A(z). Packets are then queued in a buffer until they can be 
transmitted via one of the c output channels based on a first-come-first-served 
(FCFS) discipline. The buffer has an infinite storage capacity for packets. The 
service (or transmission) of a packet can start or end at slot boundaries only. In 
this paper, the service times of the packets are assumed to be constant equal to 
s (s > 1) slots. Moreover, the service and arrival processes are assumed to be 
mutually independent. Finally, in the analysis that follows it is assumed that the 
system can reach a steady state. Such a steady state exists if the mean number 
of packet arrivals during an arbitrary slot is strictly less than the mean number 
of packets that can be transmitted from the buffer per slot, i.e., if the load 

p = sA'(l)/c<l. (1) 

Let us denote by Vk the system contents (i.e., the total number of packets 
in the buffer system, including the packets under transmission, if any) at the 
beginning of slot k and by a& the number of packet arrivals during slot k. Fur- 
thermore, let Uj^k (0 < j < s — 1) indicate the total number of packets in the 
system at the beginning of slot k whose service has progressed for at most j 
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slots. Note that no packets in the system have received more than s — 1 slots 
of service due to the constant nature of the service times (packets who have 
received s slots of service are no longer in the system) . In [7] , it was shown that 
the following set of system equations can then be established: 

V/c — 'U'S — l,fc 5 (2) 



Uj,k + 1 = Uj- i,fc + a k , for 1 < j < s - 1, 



(3) 



and 



UQ,k+l 



('Us— l,k c) “1“ Qki 



(4) 



where (••■) + = max(0,- ■ ■). We moreover introduce the notation it _ \ ik = 
(its- qfc — c) + to indicate the number of packets in the system at the beginning 
of slot k and not being served during slot k. In the steady state the distributions 
of the random variables v k and Uj )k become independent of the time index k. 
We denote by V(z) and Uj(z) the equilibrium pgf’s of v k and Uj^, respectively. 
Equations (2)-(4) were used in [7] to derive the following expressions for the 
pgf’s V(z) and Uj(z): 



V(z) 



c(l - p) 



(z- l)A(z) s 
z c - A(z) s 



C — 1 




(5) 



where Zi (1 < i < c — 1) are the c — 1 zeros inside the unit disk {z : \z\ < 1} 
of - A(z ) a , and 



U-j( z ) = f° r - 1 < j < s - 1. (6) 

’ A(z) s -3~ l ~ w 

In this paper, we will study the delay characteristics for the considered GI-D-c 
queueing model. 



3 Relationship Between System Contents and Delay 

We define the delay of a packet as the total number of slots between the end of 
the slot during which the packet arrived in the system and the end of the slot 
where the service (transmission) of the packet finishes and the packet leaves the 
system. In this section, we will derive a relationship between the steady-state 
probability distributions of the system contents at the start of an arbitrary slot 
and the delay of an arbitrary packet. For this purpose, let us consider an arbitrary 
packet P (referred to as the tagged packet), that arrives in the queueing system 
during some slot J in the steady state. Let d with pgf D(z) denote the delay of 
P. Also define the waiting time of a packet as the number of slots between the 
end of the packet’s arrival slot and the beginning of the slot where the service of 
the packet starts. Then it is clear that the delay of a packet is equal to the sum 
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of the waiting time and the service time of the packet. Hence, we can express 
the pgf D(z) as 

D(z) = z'W(z), (7) 

where W ( z ) denotes the pgf of the waiting time w of P. 

We now concentrate on the derivation of the pgf W(z). We let q denote the 
total number of packets present in the system right after slot J with service 
priority over the tagged packet P. Note that, in view of the FCFS discipline, q 
consists of the packets that arrived before slot J and have not yet finished service 
at the end of slot J on the one hand, and the packets that arrived in slot J but 
before the packet P on the other hand. In order to derive W(z), we follow the 
relationship between q and w. 

— Let us first observe the first frame of length s slots after slot J. If q < c, it is 
clear that P will get into service at the beginning of slot J + 1; otherwise, if 
q > c, P will have to wait at least 1 slot. At the end of slot J + 1, there will 
be ( u s - 2 ,j — u s - 3 t j) packets leaving the system, which is the total number 
of packets that have received exactly s — 2 slots of service at the beginning 
of slot J. In case P didn’t get into service at the beginning of slot J + 1, an 
analogous reasoning holds for slot J + 2: either the packet P will get into 
service at the beginning of slot J + 2, if q — (u s _ 2 ,j — Us- 3 ,j) < c, or the 
waiting time of P will be at least 2 slots otherwise. In the meanwhile, there 
will be {u s - 3 t j — w s _ 4 ,j) packets leaving the system at the end of slot J + 2. 
We see that the tagged packet will still be waiting for service during slot J+i, 
or in other words the waiting time of P will be at least i slots (1 < i < s), 

only if q — ( u s - 2 ,j - « s -3 ,j) - (u s -3,J ~ «s-4,j) (u s -i,j ~ u s -i-i,j) = 

q - w s _ 2 ,j + u s -i- i,j > c. 

— Next, let us observe the second frame of s slots after slot J. In case q > c, 
exactly c packets will leave the system during the first frame after slot J, and 
there will be q — c packets left in the system at the beginning of slot J + s + 1 
to be served before P. Hence, in case P didn’t yet get into service during the 
first frame after slot J, we note the following. If q — c < c, P will get into 
service at the beginning of slot J+s+1; otherwise, if q > 2c, the waiting time 
of P will be at least s + 1 slots. At the end of slot J + s + 1, all packets whose 
service started at the beginning of slot J+2 will leave the system; the number 
of these packets is (w s _ 2 ,j — u s _ 3 ,j). Then if q — c — (u s - 2 ,j — tt s - 3 ,y) > c, 
P will have to wait at least s + 2 slots before getting service. Similarly, if 

Q £ (+s— 2 ,J U s — 3 ; j) (r+— 3,J l U's—4 : j') ' (^3— i,J Us— i— l,j) 

— q C U S —2,J + + C, 

the waiting time of P will be at least s + i slots (1 < i < s). 

— In case P didn’t get into service during the second frame after slot J, there 
will be q — 2c packets in the system to be served before P at the start of the 
third frame, and we can repeat the former reasoning. 
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From the above survey, we conclude that the following relationship between the 
waiting time w of P and the random variable q holds: 

w > Is + i <t=> q — u s - 2 ,j + u s -i- 1 , j > lc + c, for l > 0, 1 < i < s. (8) 

According to the definition of q , we have 

q = vj + f - («s-i,J - u s -2,j) = / + u s -2,j, ( 9 ) 

where / is the number of packets arriving during the arrival slot of P (slot J), 
but before P. Then (8) can be further expressed as 

w > Is + i <t=> / + u s -i-i t j — c> lc, 

or equivalently 



w > Is + i <t=> qi > Ic, for l > 0, 1 < * < s, (10) 



with 

q% = f + j - c. (li) 

The next step is now to transform the relationship (10) between the random 
variables w and qi (1 < * < s) into a relationship between their pgf’s. To this 
end, we use the identity 



OO 

^Prob[w > n]z n 

n— 1 



z[W(z) - 1] 

2-1 



From this identity and equation (10), it follows that 
z c [W(z c ) - 1] 



= ^Prob[u) > n}z cn 

n= 1 

S OO 

= Pr ° b [ w > is + i]z c{ls+i) 



2—1 0 
S OO 



= EE Prob[( 7 i > lc}: 



,slc-\-ci 



i=l i= 0 



This can also be written as 
z c [W(z c ) - 1] 



z c — 1 



2=1 m = 0 



1 = 0 



( 12 ) 



= ^ z cl ^ Prob[gi > m\z sm ^ 8(m — lc), (13) 



where c>(-) is the Kronecker delta function, which is zero unless its argument is 
zero, in which case it is equal to 1. Since to > 0 in the above expression, the lower 
limit of the sum over l in (13) can be replaced by — oo without any influence on 
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the result. We can then eliminate the Kronecker delta functions from (13) by 
using the following identity: 

.. c— 1 oo 

~'^ / P Kn = ^ S(K — lc), with P = exp(27r//c), (14) 

n— 0 /= — oo 



and where I is the imaginary unit (7 2 = —1). This identity expresses that the 
left-hand side of (14) equals zero unless the integer K is a multiple of c, in which 
case it is equal to 1. By using (14) in (13), we obtain 



z c [W(z c ) - 1] 
z c — 1 



1 S c— 1 OO 

Probfgi > to] {z s j3^) m 

2=1 j= 0 m— 0 

i^ l -(3 j z s Qi(Fz s ) ci 

c z—* l-ftz 3 

i= o *=i H 



( 15 ) 



where Qi(z) is the pgf of qi , and where we have also used the identity 

1 ~ zQi(z) ^ -d ur~ \ 1 m 

= y Prob [qi > to \z . 

1 — z z — ' 

m— 0 

What remains now is to relate the pgf’s Qi(z ), 1 < i < s, to the pgf V(z) of 
the system contents v at the start of an arbitrary slot. This can be done based 
on the definition (11) of ql. In view of the uncorrelated nature of the packet 
arrival process, the random variables / and on the right-hand side of 

(11) are statistically independent. Hence, we get 



Qi{z) = 



F{z)U s -i-\{z) 



(16) 



where F(z) is the pgf of /, which can be shown to be (see e.g. [9]) 



m = ~7t 



A(z) - 1 



W(l)(z-1)’ 



Combination of (16) and (6) yields 



Ql{z) = for 1 < i < s- 



( 17 ) 



(18) 



Substituting (18) into (15), working out the sum over i, using the property that 
fF c = 1 regardless of the value of j and the identity 



it: i 






c L — ‘ 1 — /3 i z a 1 — z c 

l=o y 
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which is easily shown based on equation (14), we finally obtain 



W(z c ) 



l-z c ^ (3 j z s [A(piz s ) s - £ cs ]F(/3V)y(/3V) 
cz cs 1 - P iz s A(pi z s ) s [A{pi z s ) - z c ] 



( 19 ) 



Combination of (19) with (7) then leads to the desired relationship between the 
steady-state pgf’s of the system contents v at the beginning of an arbitrary slot 
and the delay d of an arbitrary packet. 



4 Delay Characteristics 



From the above relationship between system contents and delay and the known 
expression (5) for the pgf V(z) of the system contents, we find the following 
explicit formula for the pgf of the delay experienced by an arbitrary packet in 
the steady state: 



D(z c ) = z cs W(z c ) 



1 — P \ ' 
A'( 1) ^ 

V ’ 3 = 0 



l-z c A(piz s ) - 1 
1 - (P^z 8 )- 1 A(piz s ) - z c 



n 



p j z s - Zi 
1 - Zi 



( 20 ) 



In the rest of this section, we will use the expression for D(z c ) to derive some 
important characteristics of the packet delay. 



4.1 Moments of the Delay 

The mean value of the packet delay can be found by evaluation of the first-order 
derivative of the pgf D(z c ) with respect to z at z = 1. Specifically, 



m = D\i) 



1 dD(z c ) 
c dz 



(21) 



where D(z c ) is given in (20). After some mathematical manipulations, we find 



E[d] 



E[v\ 

A{iy 



( 22 ) 



which proves that our result fully agrees with Little’s theorem ([10]). In a similar 
way, we can also obtain higher-order moments of the packet delay from (20), 
by calculating the appropriate higher-order derivatives of D(z c ) at z = 1. For 
instance, the variance of the packet delay (delay jitter) can be expressed as 



Var[d ] =L»"(1) + D'(1)-D'(1) 2 , 



(23) 



where D (1), the second derivative of D(z) in z = 1, can be obtained from (20) 
as 



D"{ 1) 



1 d 2 P{z c ) 
c 2 dz 2 



c — 1 



d\ i). 






C 



Delay Analysis for a Discrete-Time GI-D-c Queue 



191 



4.2 Tail Probabilities of the Delay 

The aim of this section is to determine the tail distribution of the packet delay, 
i.e. , the probability that the delay equals a given value n, for a sufficiently large 
value of n. In principle, the tail distribution of a discrete random variable can 
be determined by applying the inversion formula for ^-transforms and Cauchy’s 
residue theorem from complex analysis (see e.g. [11]) on its generating function 
and keeping only the contribution of the pole (or poles) of the pgf with smallest 
modulus outside the unit disk, as explained in [9]. From the expression (20) for 
D(z c ), we find that D(z c ) has c poles with the same smallest modulus. These 
poles are given by 

z d (m) = (3~ m zl ,s , for m = 0, •■•,c-l, (24) 



where z v is the dominant pole of the pgf V(z) of the system contents, i.e., the 
zero of z c — A(z) s outside the unit disk with the smallest modulus. Indeed, it 
is easy to show that z d ( 0) = z^ s is the zero with minimal modulus outside 
the unit disk of the factor [z c — A(z s )] in the denominator of D(z c ). Moreover, 
since z c remains unchanged when z is multiplied by /3 -m , it is clear that Zd(m) = 
l3~ m zl^ s is also a pole of D(z c ) with the same modulus z v x ! s . In particular, it 
can be shown that the pole Zd(m) is a zero of the factor \A(J& z s ) — z c ] in the 
denominator of D(z c ) for which j = (ms) mod c, i.e., for which j equals the 
remainder of the division of ms by c. Taking into account all the poles Zd(m) 
of D(z c ) with minimal modulus and keeping in mind that Prob[d = n\ is the 
coefficient of z cn in the series expansion of D(z c ), we finally obtain the following 
expression for Prob[d = n] for sufficiently large n: 



Prob[d = n] 
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m— 0 



bm 

z d (m) 



[z d (m)]- cn 
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m — 0 
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^ v 
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(25) 



where b m is the residue of D(z c ) in the point z = Zd(m ) and where we have used 
the property that /3 mc = 1. The residue b m is given by 

b _ N m (zd(m )) 
m ~ R m '(z d (m))’ 

where N m (z) and R m (z) are the numerator and the denominator, respectively, 
of the term of (20) corresponding with the index value j = (ms) mod c. Using 
the expression (20), we find 



c*= E 

m— 0 



b(m) 

z d (m) 



c(l - p) 1 - Zy S A(z v ) - 1 y-r Z v - Zj 

A (l) 1 - (zv)- 1 sz v A'(z v ) - cz v °/ s AJ- i — Zi 
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The probability that the packet delay exceeds a given threshold T can be easily 
derived from (25) as 



-cT/s 

Prob [d>T]*-C d * v (27) 

Z v ' - 1 - 



5 Numerical Results 



In order to illustrate the results obtained above, let us consider a number of 
numerical examples. Throughout this section, we assume the number of packets 
that arrive during a slot has a geometric distribution, i.e. , 



A(z) 



1 

1 + X-Xz' 



where A denotes the mean number of packet arrivals per slot. 

In Fig. 1, the mean packet delay is plotted versus the load p for various values 
of the number of servers c and the length of the service times s. For given values 
of c and s, we observe that the mean packet delay increases with increasing values 
of p. We also note that all the curves have a vertical asymptote at p = 1. For 
a given p, the mean delay increases as the service times become longer, although 
a higher number of servers can compensate this effect to some extent. 

In Fig. 2, the variance of the packet delay is shown versus p, for c = 4 and 
for .3 = 1, 4 and 8. We see that for given values of c and p, the variance of the 
packet delay also increases as the length of the service times increases. 

In Fig. 3, the probability that the delay exceeds some given threshold T is 
plotted versus T for p = 0.8, s = 5 and for three different numbers of servers, 
namely c = 1, 4 and 8. Clearly, the probability of having long delays decreases 
as the number of servers increases, in accordance with our intuitive feeling. 
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Fig. 2. Variance of the packet delay versus load p, for c = 4 




Fig. 3. Tail distribution of packet delay, Prob[d > T], versus T, for p = 0.8 and s = 5 

6 Conclusion 

In this paper, we have studied the delay performance of a discrete-time GI-D-c 
queueing system with multiple servers, constant service times of arbitrary length 
and a general independent arrival process. The study is an extension of previous 
work (["]), which was concerned with the analysis of the system contents for this 
type of multiserver queueing system. In the present paper, we have established 
a relationship between the pgf’s of the packet delay and the system contents, 
using an analytical technique based on generating functions. Then from the result 
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for the pgf of the system contents, known from [7], we have obtained an explicit 
expression for the pgf of the packet delay, as well as closed-form expressions for 
the mean value, the variance and the tail distribution of the packet delay. The 
obtained results are easy to evaluate numerically. Some numerical results have 
been presented to illustrate the analysis. 

The analyzed queueing model has practical applications in the domain of 
digital communication networks, such as traffic concentrators, ATM switching 
elements and circuit-switched TDMA systems. Let us take a traffic concentra- 
tor as an example to see how the modeling works. A concentrator is used to 
merge a large number of low-speed lines (inputs) to a smaller number (say c) 
of high-speed lines (outputs). Fixed-length messages enter the concentrator via 
the inputs and are temporarily stored in the buffer inside the concentrator until 
they can be transmitted via one of the outputs. In case the transmission time 
is s slots for each message, the concentrator can be described as the model we 
studied, where the pgf A(z) describes the accumulated numbers of message ar- 
rivals via all the inputs of the concentrator. Readers are recommended to refer 
to [7] and [9] (Chapter 1) for more details and more applications. We note that 
besides the characteristics of the system contents studied in [7] for the consid- 
ered model, the derived results for the packet delay (i.e. , performance measures 
like the mean delay, the delay jitter and the probability that the packet delay 
exceeds a given threshold) are also very important for a network designer to 
guarantee the quality of service of the network. 
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Abstract. Active Queue Management (AQM) takes a trade-off between link 
utilization and delay experienced by data packets. From control point of view, it 
is rational to regard AQM as a typical regulation system. Recently many AQM 
algorithms have been proposed to address performance degradations of end-to- 
end congestion control. However, these AQM algorithms show weaknesses to 
detect and control congestion under dynamically changing network situations. 
In this paper, an adaptive fuzzy AQM is designed to congestion avoidance in 
TCP/AQM networks. This kind of control action has robust performance, which 
is suitable for time varying and complex systems such as computer and 
communication networks. A candidate Lyapunov function is employed in the 
adaptive law synthesis to ensure convergence. A simulation study over a wide 
range of IP traffic conditions shows the effectiveness of the proposed controller 
in tenns of the queue length dynamics, the packet loss rates, and the link 
utilization. Also, a complete comparison between the proposed fuzzy adaptive 
controller and classic Proportional-Integral (PI) controller is made, which the 
former has superior performance. 



1 Introduction 

TCP congestion control mechanism, while necessary and powerful, are not sufficient 
to provide good service in all circumstances, specially with the rapid growth in size 
and the strong requirements to Quality of Service (QoS) support, because there is a 
limitation to how much control can be accomplished at end system. It is needed to 
implement some measures in the intermediate nodes to complement the end system 
congestion avoidance mechanisms. Active Queue Management (AQM), as one class 
of packet dropping/marking mechanism in the router queue, has been recently 
proposed to support the end-to-end congestion control in the Internet [1-5]. It has 
been a very active research area in the Internet community. The goals of AQM are (1) 
reduce the average length of queue in routers and thereby decrease the end-to-end 
delay experimented by packets, and (2) ensure the network resources to be used 
efficiently by reducing the packet loss that occurs when queues overflow. AQM 
highlights the tradeoff between delay and throughput. By keeping the average queue 
size small, AQM will have the ability to provide greater capacity to accommodate 
nature-occurring burst without dropping packets, at the same time, reduce the delays 
seen by flow, this is very particularly important for real-time interactive applications. 
RED [6,7] was originally proposed to achieve fairness among sources with different 
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burst attributes and to control queue length, which just meets the requirements of 
AQM. However, many subsequent studies verified that RED is unstable and too 
sensitive to parameter configuration, and tuning of RED has been proved to be a 
difficult job [8-10]. 

Fuzzy logic controllers have been developed and applied to nonlinear system for 
the last two decades [11]. The most attractive feature of fuzzy logic control is that the 
expert knowledge can be easily incorporated into the control laws [12-14]. In [15,16] 
an adaptive fuzzy controllers has been proposed for robust control performance, 
which will be used in our controller design. 

The intuition and heuristic design is not always scientific and reasonable under any 
conditions. Of course, since Internet is a rather complex huge system, it is very 
difficult to have a full-scale and systematic comprehension, but importance has been 
considerably noted. The mathematical modeling of the Internet is the first step to have 
an in-depth understanding, and the algorithms designed based on the rational model 
should be more reliable than one original from intuition. In some of the references, 
the nonlinear dynamic model for TCP flow control has been utilized and some 
controllers like PI and Adaptive Virtual Queue Algorithm have been designed for that 
[17-21], 

Although PI controller successfully related some limitations of RED, for instance, 
the queue length and dropping/marking probability are decoupled, whenever the 
queue length can be easily controlled to the desired value; the system has relatively 
high stability margin. The shortcomings of PI controller are also obvious. The 
modification of probability excessively depends on buffer size. As a result, for small 
buffer the system exhibits sluggishness. Secondly, for small reference queue length, 
the system tends to performance poorly, which is unfavorable to achieve the goal of 
AQM because small queue length implies small queue waiting delay. Thirdly, the 
status of actual network is rapidly changeable, so we believe that it is problematic and 
unrealistic, at least inaccurate, to take the network as a linear and constant system just 
like the designing of PI controller. Affirmatively, the algorithm based on this 
assumption should have limited validity, such as inability against disturbance or 
noise. We need more robust controller to adapt complex and mutable network 
environment, which will be our motivation and aim in this study. 

In the paper, we will apply an adaptive fuzzy controller to design the AQM system 
for congestion avoidance. First, a fuzzy logic based controller is designed and them 
the adaptive law will be applied to the designed controller. A candidate Lyapunov 
function is employed in the adaptive law synthesis to ensure convergence. The 
performance of the proposed fuzzy adaptive controller is compared with that of 
classic PI controller. The simulation results show the superior performance of the 
proposed controller in comparison with classic PI controller. 

The rest of the paper is organized as follows: Section 2 presents the nonlinear 
dynamic model for TCP flow control and the state space description of this model. In 
Section 3, the basic principles of adaptive fuzzy controller are presented. Some 
simulations are provided using MATLAB package in Section 4 and the performance 
of the various controllers are compared. Finally, the paper is concluded in section 5. 
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2 TCP Flow Control Model 



In [17], a nonlinear dynamic model for TCP flow control has been developed based 
on fluid-flow theory. This model can be stated as follows 



dW(t) 
dt 
dq(t ) 
dt 



1 



W(t)W(t - R(t )) 



m 

N(t) 

m 



2R(t) 
W(l)-C(t) 



p(t-R(t)) 



(1) 



The above nonlinear and time -varying system was approximated as a linear 
constant system by small-signal linearization about an operating point [20,21] 
(Fig. 1). In the block diagram, C(s) and G(s) are the controller and the plant, 
respectively. The meaning of parameters presented in Fig. 1 are as following 
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[doctor 
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m = R(t), 



T 2 (t) = 



R 2 (t)C(t ) 
2 N(t) 



(2) 



where 

C(t) : Link capacity (packets/sec) 

q 0 : Queue reference value 

N(t) : Load factor, i.e., number of active sessions 

R(t) : Round-trip time (RTT), R(t) = l(q(t) / C(t) + T p \ T p is the fixed 
propagation delay 

p(t) : Dropping/marking probability 
q(t) : Instantaneous queue 

We believe that the AQM controller designed with the simplified and inaccurate 
linear constant model should not be optimal, because the actual network is very 
changeful; the state parameters are hardly kept at a constant value for a long time 
[2,5]. Moreover, the equations (1) only take consideration into the fast retransmission 
and fast recovery, but ignore the timeout mechanism caused by lacking of enough 
duplicated ACK, which is very usual in burst and short-lived services. In addition to, 
there are many non-respective UDP flows besides TCP connections in networks; they 
are also not included in equations (1). These mismatches in model will have negative 
impact on the performance of controller designed with the approach depending with 
the accurate model. For the changeable network, the robust control should be an 
appropriate choice to design controller for AQM. 

To describe the system in state space form, suppose that x { =e, x 2 = del dt , so the 
plant depicted in Fig. 1 is described by a second order system as 

dx i 

= x 2 

dt 
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dx i 

— — = -a x {t)x x -a 2 ( t)x 2 - b(t) + F(t) 
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F(t) is regarded as the system disturbance. 
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Fig. 1. Block diagram of AQM control system 



3 Fuzzy Adaptive Controller Design 

3.1 Fuzzy Control Design 

Fuzzy logic control (FLC) has been demonstrated to solve some practical problems 
that have been beyond the reach of conventional control techniques. Fuzzy logic 
control is a knowledge -based control that uses fuzzy set theory, fuzzy reasoning and 
fuzzy logic for knowledge representation and inference [11,12,16]. The apparent 
success of FLC can be attributed to its ability to incorporate expert information and 
generate control surfaces whose shape can be individually manipulated for different 
regions of the state space with virtually no effects on neighboring regions. 

In this paper a fuzzy system consisting of a fuzzifier, a knowledge base (rule base), 
a fuzzy inference engine and defuzzier will be considered. The knowledge base of the 
fuzzy system is a collection of fuzzy IF-TF1EN rules. Fuzzy logic control is ideal for 
the AQM problem, since there is no complete mathematical model. Flowever, human 
experience and experimental results, can be used in the control system, design. 

The controller has two inputs, the error (e) and its derivative (e) and the control 

input ( p) . Five triangular membership functions are defined for error (Fig. 2), 
namely. Negative Large (NL), Negative Small (NS), Zero, Positive Small (PS), and 
Positive Large (PL). Similarly three triangular membership functions are defined for 
derivative of the error (Fig. 3) and there are as follows, Negative Small (NS), Zero, 
and Positive Small (PS). Also five triangular membership functions are defined for 
the control input (Fig. 4) and there are Zero, Small, Medium, Large and Very Large. 
The complete fuzzy rules are shown in Table 1. The first rule is outlined below, 
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Rule 1: 



If (e) is PL AND (e) is Zero THEN ( p ) is Large. 

The rest of the rules are derived similarly. The label names used here give an intuitive 
sense of how the rules apply. Through experimentation and tuning of the membership 
functions it was determined that the number of rules was sufficient to encompass all 
realistic combinations of inputs and outputs. This fuzzy logic controller is 
implemented using product inference and a center-average defuzzifier. 



Table 1. Fuzzy Rules 
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Fig. 2. Error membership function 
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3.2 Adaptive Fuzzy Control 

Assume that the rule base consists of multiple-input single-output (MISO) rules of the 
form 

R 0) : IF x, is A I and . . . and x n is A J n THEN y j is C’ (6) 

where x = (x I ...x n )e N , V denotes the linguistic variables associated with inputs 
and outputs of the fuzzy system. Af and C J are linguistic values of linguistic 
variables X and y in the universes of discourse N and S respectively, 
j =1,2 ...Q r (number of rules). A fuzzy system consisting of a singleton fuzzifier, 
product inference, center-average defuzzifier and triangular membership functions 
can be written as [14] 

,, , V-A n>,w) 



(7) 
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where / N <z 9P " -> 91 , x = (x ; . . . x„ ) r £ N and jj ^ ( x . ) is a triangular membership 
function and y J is the point in S were fi (: is maximum or equal to 1 .If the ^ (x )' s 
and y J 's are free (adjustable) parameters, then (7) can be written as 



/(*)=#¥(*) ( 8 ) 

where $ = (v 1 ,... v Qr ) is a parameter vector and ]P(x) = (^r 1 (x), . . . (x)) 7 is a 

regression vector with the regressor given by 



Vi M 



nX/W 

ztfn 



(9) 



Equation (8) is referred to as adaptive fuzzy systems [14-16]. There are two main 
reasons for using adaptive fuzzy systems as building blocks for adaptive fuzzy 
controllers. Firstly, it has been proved in [14] that they are universal function 
approximators. Secondly, all the parameters in 'F(x) can be fixed at the beginning 
of adaptive fuzzy systems expansion design procedure, so that the only free design 
parameters are $ . In this case fix) is linear in the parameters. This approach will 
be adopted in synthesizing the adaptive control law in this paper. The advantage of 
this approach is that very simple linear parameter estimation methods can be used to 
analyze and synthesize the performance and robustness of adaptive fuzzy systems. If 
no linguistic rules are available, the adaptive fuzzy system reduces to a standard 
nonlinear adaptive controller. 



3.3 Adaptive Law Synthesis 

The mathematical model given by equation (3) can be expressed as 

z = Az + Bu + E(z) (10) 

where A is Hurwitz. Therefore there exists a unique positive definite matrix P that 
satisfies the Lyapunov equation. 

A t P + PA = -Q (11) 

If the control input, u , is expressed as an adaptive fuzzy system then (10) 
becomes, 

z = Az + B?? T ^(z) + E(z) (12) 

Let [15,16], 

z = Az + B t?* T (/(z) (13) 

be the ideal systm model with no uncertainty (identification model) with £ = z — z , 
where $ denotes the optimal l9 defined as, 
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if = arg m j n 



sup u(z I if) - u(z I t?) 



Therefore, 

e = Ae + B0 J t//(£) + E 



(14) 



(15) 



where (f> = l}- $ .To derive a control law that ensures that £ — > 0 as t-A°° a 
candidate Lyapunov function is defined as [14,16]; 
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£ T Ve + 
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(16) 



where y > 0 is a design parameter. The time derivative of V is 



V = -£ t Q£ + f r PB(E + (j ) >(£•)) - 



r \\ l 



(17) 



Rearranging equation (17) yields 

V = -e T Qe + £- t PBE + f (?j|£'||||f : r PB||^(f) + i] (18) 

Now choosing the adaptive law (recalling that ip — 'd-') 

& = -*^||E||||f 7 'P5||^(f) (19) 

The equation (18) reduces to 

Y=-£ t Q£ + £ t PBE (20) 

The equation (21) can be recast using vector norms; 

V = ^ min (0)|H 2 +||c T PB||||E|| (21) 

Let i^il be selected such that 

IeIK Adelf -«H ( 22) 

11 11 llcPBlI 



where a > 0 , substituting for E in equation (22) gives 

V < -o\\e\\ (23) 

Therefore the control law of equation (19) will ensure that the state £ converges. 
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4 Simulation Results 

The network topology used for simulation, is depicted in Fig. 5 [2,5]. The only 
bottleneck link lies between node A and node B. the buffer size of node A is 200 
packets, and default size of the packet is 350 bytes. All sources are classed into three 
groups. The first one includes Aj greedy sustained FTP application sources, the 
second one is composed of A 2 burst FITTP connections, each connection has 10 
sessions, and the number of pages per session is 3. The thirds one has A 3 UDP 
sources, which follow the exponential service model, the idle and burst times are 
10000msec and 1000msec, respectively, and the sending rate during "on" duration is 
40kbps. We introduced short-lived FITTP flows and non-responsive UDP services 
into the router in order to generate a more realistic scenario, because it is very 
important for a perfect AQM scheme to achieve full bandwidth utilization in the 
presence of noise and disturbance introduced by these flows. The links between node 
A and all sources have the same capacity and propagation delay pair ( L x , r, ) . The 

pair ( 1 , 2 ^ 2 ) and (C 3 , r 3 ) define the parameter of links AB and BC, respectively. 




Fig. 5. The simulation network topology 



In the first study, we will use the most general network configuration to testify 
whether the proposed Adaptive Fuzzy Logic Controller (AFLC) can reach the goals 
of AQM, and freely control the queue length to stabilize at the arbitrary expected 
value. Therefore, given that (L 1 , T x )= (l0Mbps,\5ms) , (l 2 , r 2 ) = (l 5Mbps, \ 5ms ) , 
(i 3 , r 3 ) = (45Mbps ,15 ms) . N { =270, A 2 =A 3 = 0. Let the expected queue length 
equal to 75 packets. To implement the control law, the fuzzy rule Table 1 is used and 
the insight gained from the non-adaptive fuzzy logic control is used to select the $ 
values to lie within the interval [1.0, 2.0]. The remaining control parameters are set as: 
Q=diag(3,3), E = 120 , y = 0.00025 . V P(£’) is formulated using the IF part of 
fuzzy rule Table 1 . 

The instantaneous queue length using the proposed AFLC is depicted in Fig. 6. 
After a very short regulating process, the queue settles down its stable operating point. 
RED algorithm is unable to accurately control the queue length to the desired value 
[7,9]. The queue length varies with network loads. The load is heavier the queue 
length is longer. Attempting to control queue length through decreasing the interval 
between high and law thresholds, then it is likely to lead queue oscillation. 
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To investigate the performance of the proposed AFLC, we will consider a classic 
PI controller as 

p(k) = (a- b)(q{k ) -q a ) + b(q(k) - q(k - 1)) + p(k - 1) (24) 

The coefficients a and b are fixed at 1.822e' 5 and 1.81 6e" 5 , respectively, the 
sampling frequency is 500Hz, the control variable p is accumulative [5]. Because the 
parameter b is very small, and the sample interval is very short, the negative 
contribution to p made by the second item in the right can be omitted in initial 
process, then the positive contribution mainly come from the first item. The queue 
evaluation using PI controller is shown in Fig. 7. Although PI controller could 
regulate the queue to the fixed point, the integrated performance needs to be 
improved, such as the transient process is too long and the fluctuation in steady state 
is great, for small queue length, which lows the link utilization. 





Fig. 7. Queue evaluation (PI) 



In this section. Firstly, let N x =270, N 2 = 400,7V 3 = 0, the evaluation of queue 
size is shown in Fig. 8. As it can be seen, the proposed AFLC has better performance 
than that of PI one. Next, given that IV) = 270, N 2 = 0, _/V 3 = 50, we further investigate 
performance against the disturbance caused by the non-responsive UDP flows. Fig. 9 
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shows the results, obviously, PI is very sensitive to this disturbance, while AFLC 
operates in a relatively stable state. The queue fluctuation increases with introducing 
the UDP flows, but the variance is too much smaller comparing with PI controller. 




Fig. 8. Queue evaluation (FTP+HTTP) 




Fig. 9. Queue evaluation (FTP+UDP) 

Finally, we evaluate the integrated performance of AFLC using one relatively real 
scenario, i.e., the number of active flows is changeable, which has 270 FTP flows, 
400 HTTP connections and 30 UDP flows. Figs. 10 and 11 show the evaluation of 
queue controlled by AFLC and PI controllers, respectively. It is clear that the 
integrated performance of AFLC controller, namely transient and steady state 
responses is superior to that of PI controller. The AFLC controller is always keeping 
the queue length at the reference value, even if the network loads abruptly change, but 
PI controller has the inferior adaptability. In other words, the former is more 
powerful, robust and adaptive than the later one, which is in the favor of achievement 
to the objectives of the AQM policy. 
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Fig. 10. Queue evaluation (AFLC) 
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Fig. 11. Queue evaluation (PI) 

5 Conclusions 

In this paper, an adaptive fuzzy logic based controller was applied to TCP/AQM 
networks for the objective of queue management and congestion avoidance. For this 
purpose, a linearized model of the TCP flow was considered. A candidate Lyapunov 
function is employed in the adaptive law synthesis to ensure convergence. We took a 
complete comparison between performance of the proposed AFLC and classical PI 
controller under various scenarios. The conclusion was that the integrated 
performance of AFLC was superior to that of PI one. 
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Abstract. Instruction level multithreading is a technique for tolerating 
long-latency operations (e.g., cache misses) by switching the processor to 
another thread instead of waiting for the completion of a lengthy opera- 
tion. In block multithreading, context switching occurs for each initiated 
long-latency operation. However, processor cycles during pipeline stalls 
as well as during context switching are not used in typical block mul- 
tithreading, reducing the performance of a processor. Dual block multi- 
threading introduces a second active thread which is used for instruction 
issuing whenever the original (main) thread becomes inactive. Dual block 
multithreading can be regarded as a simple and specialized case of si- 
multaneous multithreading when two (simultaneous) threads are used 
to issue instructions for a single pipeline. The paper develops a simple 
timed Petri net model of a dual block multithreading and uses this model 
to estimate the performance improvements of the proposed dual block 
multithreading. 

Keywords: Block multithreading, instruction issuing, pipelined proces- 
sors, timed Petri nets, performance analysis, event-driven simulation. 



1 Introduction 

Continuous progress in manufacturing technologies results in the performance of 
microprocessors that has been steadily improving over the last decades, doubling 
every 18 months (the so called Moore’s law [4]). At the same time, the capacity 
of memory chips has also been doubling every 18 months, but the performance 
has been improving less than 10% per year [5]. The latency gap between the pro- 
cessor and its memory doubles approximately every six years, and an increasing 
part of the processor’s time is spent on waiting for the completion of memory 
operations [8]. Matching the performances of the processor and the memory is 
an increasingly difficult task [9]. 

Techniques which tolerate long-latency memory accesses include out-of- 
order execution of instructions and instruction-level multithreading. The idea of 
out-of-order execution is to execute, during the waiting for the completion of 
a long-latency operation, instructions which (logically) follow the long-latency 
one, but which do not depend upon the result of this long-latency operation. 
Since out-of-order execution exploits instruction-level concurrency using the 
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existing sequential instruction stream, it conveniently maintains code-base com- 
patibility [6]. In effect, the instruction stream is dynamically decomposed into 
micro-threads, which are scheduled and synchronized at no cost in terms of ex- 
ecuting additional instructions. Although this is desirable, speedups using out- 
of-order execution on superscalar pipelines are not so impressive, and it is diffi- 
cult to obtain a speedup greater than 2 using 4 or 8- way superscalar issue [11]. 
Moreover, memory latencies are so long that out-of-order processors require 
very large instruction windows to tolerate them. A cache miss to main memory 
costs about 128 cycles on Alpha 21264 [13] and 330 cycles on a Pentium-4-like 
processor [10]. Large instruction windows mean design complexity, verification 
difficulty and increased power consumption [7], so the industry is not moving 
toward the wide-issue superscalar model [1]. In effect, it is often the case that 
up to 60 % of execution cycles are spent waiting for the completion of memory 
accesses [7]. 

Instruction-level multithreading [2], [3] tolerates long-latency memory ac- 
cesses by switching to another thread (if it is available for execution) rather than 
waiting for the completion of the long-latency operation. If different threads are 
associated with different sets of processor registers, switching from one thread 
to another (called “context switching”) can be done very efficiently [12]. 

In block multithreaded processors, the pipeline is stalled occasionally for 
one or more processor cycles because of the instruction dependencies. Since the 
trend in modern microprocessors is to increase the depth of the pipelines [10], 
and deep pipelines increase the probability of pipeline stalls due to instruction 
dependencies, the effects of pipeline stalls on the performance of processors can 
be quite significant. This paper proposes a variant of block multithreading in 
which an additional active thread is used to issue instruction in those processor 
cycles in which the main thread is inactive. The proposed approach is called dual 
block multithreading. 

The main objective of this paper is to study the performance of dual block 
multithreaded processors in order to determine how effective the addition of the 
second active thread can be. A timed Petri net [14] model of multithreaded pro- 
cessors at the instruction execution level is developed, and performance results 
for this model are obtained by event-driven simulation. Since the model is rather 
simple, simulation results can be verified (with respect to accuracy) by state- 
space-based performance analysis (for combinations of modeling parameters for 
which the state spaces remains reasonably small). 

2 Petri Net Models 

A timed Petri net model of a simple block multithreaded processor at the in- 
struction execution level is shown in Fig.l (as usually, timed transitions are 
represented by solid bars, and immediate ones, by thin bars). For simplicity, 
Fig.l shows only one level of memory; this simplification is removed further in 
this section. 
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Fig. 1 . Petri net model of a block multithreaded processor 



Ready is a pool of available threads; it is assumed that the number of of 
threads is constant and does not change during program execution (this as- 
sumption is motivated by steady-state considerations). If the processor is idle 
(place Next is marked) , one of available threads is selected for execution (transi- 
tion Tsel). Pnxt is a free-choice place with three possible outcomes: TstO (with 
the choice probability p s o) represents issuing an instruction without any further 
delay; Tstl (with the choice probability p s i) represents a single-cycle pipeline 
stall (modeled by Tdl ), and Tst-2 (with the choice probability p s 2 ) represents 
a two-cycle pipeline stall ( Td2 and then Tdl)-, other pipeline stalls could be rep- 
resented in a similar way, if needed. Cont, if marked, indicates that an instruction 
is ready to be issued to the execution pipeline. Instruction execution is modeled 
by transition Trim which represents the first stage of the execution pipeline. It 
is assumed that once the instruction enters the pipeline, it will progress through 
the stages and, eventually, leave the pipeline; since these pipeline implementa- 
tion details are not important for performance analysis of the processor, they 
are not represented here. 

Done is another free-choice place which determines if the current instruction 
performs a long-latency access to memory or not. If the current instruction is 
a non-long-latency one, Tnxt occurs (with the corresponding probability), and 
another instruction is fetched for issuing. If long-latency operation is detected in 
the issued instruction, Tend initiates two concurrent actions: (i) context switch- 
ing performed by enabling an occurrence of Tcsw, after which a new thread is 
selected for execution (if it is available), and (ii) a memory access request is 
entered into Mreq, the memory queue, and after accessing the memory (transi- 
tion Tmem ), the thread, suspended for the duration of memory access, becomes 
“ready” again and joins the pool of threads Ready. 
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Fig. 2. Petri net model of a block multithreaded processor with a two-level memory 



The choice probability associated with Tend determines the runlength of 
a thread, £ t , i.e., the average number of instructions between two consecutive 
long-latency operations; if this choice probability is equal to 0.1, the runlength 
is equal to 10, if it is equal to 0.2, the runlength is 5, and so on. 

The number of memory ports, i.e., the number of simultaneous accesses to 
memory, is controlled by the initial marking of Mem ; for a single port memory, 
the initial marking assigns just a single token to Mem , for dual-port memory, 
two tokens are assigned to Mem, and so on. 

In a similar way, the number of simultaneous threads (or instruction issue 
units) is controlled by the initial marking of Next. For a model of dual block 
multithreading, the initial marking of Next is 2. 

Memory hierarchy can be incorporated into the model shown in Fig.l by 
refining the representation of memory. In particular, levels of memory hierarchy 
can be introduced by replacing the subnet Tmem-Mem by a number of subnets, 
each subnet for one level of the hierarchy, and adding a free-choice structure 
which randomly selects the submodel according to probabilities describing the 
use of the hierarchical memory. Such a refinement, for two levels of memory, is 
shown in Fig. 2, where Mreq is a free-choice place selecting either level-1 (sub- 
model Mem-Tmeml) or level-2 (submodel Mem-Tmem2). 

The effects of memory hierarchy can easily be compared with a uniform, 
non-hierarchical memory by selecting the parameters in such a way that the 
average access time of the hierarchical model (Fig. 2) is equal to the access time 
of the non-hierarchical model (Fig.l). 

For convenience, all temporal properties of the model are expressed in pro- 
cessor cycles, so, the occurrence times of Trun, Tdl and Td2 are all equal to 1 
(processor cycle), the occurrence time of Tcsw is equal to the number of pro- 
cessor cycles needed for context switching (which is equal to 1 for many of the 
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Table 1 . Block multithreading modeling parameters and their typical values 



symbol 


parameter 


value 


n t 


number of available threads 


1,— ,10 


it 


thread runlength 


10 


tcs 


context switching time 


1,5 


tm 


average memory access time 


10 


Ps 1 


prob. of one-cycle pipeline stall 


0.2 


Ps2 


prob. of two-cycle pipeline stall 


0.1 



following performance analyses), and the occurrence time of Tmem is the average 
number of processor cycles needed for a long-latency access to memory. 

The main modeling parameters and their typical values are summarized in 
Tab.l. The number of available threads, n*, changes from 1 to 10 in order to 
check if a large number of threads has can provide a reasonable improvement of 
the processor’s performance. Thread runlength, i t , equal to 10 corresponds to 
the (primary) cache miss of 10%. Context switching times equal to 1 and 5 are 
used to check the sensitivity of performance results on the duration of context 
switching. The average memory access time, f m , of 10 processor cycles matches 
the thread runlength, £ t , providing the balanced utilization of the processor and 
the memory; if t m > it, the memory becomes the bottleneck which limits the 
performance of the system; if £ t > t rn , the memory has little influence on the 
system’s performance. The probabilities of pipeline stalls, p s \ and p s 2 , correspond 
to the probabilities of data hazards used in [5]. 

3 Performance Results 

The utilization of the processor, as a function of the number of available threads, 
for a “standard” processor (i.e., a processor with a single instruction issue unit) 
is shown in Fig. 3. 

The asymptotic value of the utilization can be estimated from the (average) 
number of empty instruction issuing slots. Since the probability of a single-cycle 
stall is 0.2, and probability of a two-cycle stall is 0.1, on average 40 % of issuing 
slots remain empty because of pipeline stalls. Moreover, there is an overhead 
of t cs = 1 slot for context switching. The asymptotic utilization is thus 10/15 = 
0.667, which corresponds very well with Fig. 3. 

The utilization of the processor can be improved by introducing a second (si- 
multaneous) thread which issues its instructions in the unused slots. Fig. 4 shows 
the utilization of a dual block multithreaded processor, i.e., a processor issuing 
instructions to a single instruction execution pipeline from two (simultaneous) 
threads. 

The utilization of the processor is improved by about 40 %. 

A more realistic model of memory, that captures the idea of a two-level 
hierarchy, is shown in Fig. 2. In order to compare the results of this model with 
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Processor utilization (1) 




Fig. 3. Processor utilization for standard block multithreading; It = 10, t m = 10, t cs = 

1, p 3 i = 0.2, p s2 = 0.1 



Processor utilization (2) 




Fig. 4. Processor utilization for dual block multithreading; It = 10, f m = 10, t cs = 

1, pai = 0.2, p s2 = 0.1 



Fig. 3 and Fig. 4, the parameters of the two-level memory are chosen in such 
a way that the average memory access is equal to the memory access time in 
Fig.l (where t m = 10). Let the two levels of memory have access times equal to 
8 and 40, respectively; then the choice probabilities are equal to 15/16 and 1/16 
for level-1 and level-2, respectively, and the average access time is: 



15 1 
: *l6 +40 *i6 



10 . 



The results for a standard block multithreaded processor with a two-level 
memory are shown in Fig. 5, and for a dual block multithreaded processor in 
Fig. 6. 

The results in Fig. 5 and Fig. 6 are practically the same as in Fig. 3 and Fig. 4. 
This is the reason that the remaining results are shown for (equivalent) one- 
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Processor utilization (1&2) 




Fig. 5. Processor utilization for standard block multithreading with 2-level mem- 
ory; l t = 10, t m = 8 + 40, t ca = 1, Psl = 0.2, p s2 = 0.1 



Processor utilization (2&2) 




number of available threads 

Fig. 6. Processor utilization for dual block multithreading with 2-level memory; It = 
10, tm = 8 + 40, t cs = 1, Psl = 0.2, p s2 = 0.1 



level memory models; the multiple levels of memory hierarchy apparently have 
no significant effect on the performance results. 

Dual multithreading is also quite flexible with respect to context switch- 
ing times because the additional thread fills the instruction issuing slots which 
normally would remain empty during context switching. Fig. 7 compares the uti- 
lization of the standard block multithreaded processor with t cs = 1 (broken line) 
and t cs = 5 (solid line). The reduction of the processor’s utilization for t cs = 5 
is about 20 %, and is due to the additional 4 cycles of context switching which 
remain empty (out of 19 cycles, on average). 

Fig. 8 compares utilization of the dual block multithreaded processor for t cs = 
1 and t cs — 5. The reduction of utilization is much smaller in this case and is 
within 10 %. 
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Processor utilization (1) 




Fig. 7. Processor utilization for standard block multithreading; It = 10, t m = 10, t cs = 
1, 5, psi = 0.2, p 3 2 = 0.1 



Processor utilization (2) 




number of available threads 

Fig. 8. Processor utilization for dual block multithreading; It = 10, f m = 10, t cs = 
1, 5, Pal = 0.2, p s2 = 0.1 

4 Concluding Remarks 

Dual block multithreading discussed in this paper is a means to increase the 
performance of processors by tolerating long-latency operations (block multi- 
threading) and pipeline stalls (dual multithreading). Its implementation is rather 
straightforward while the improvement of the utilization of processors can be 
quite significant, as shown in Fig. 9. 

However, the improved performance of dual multithreading can be obtained 
only if the system is balanced, or if the processor is the system’s bottleneck. 
Fig. 10 shows the utilization of the processor for standard (solid line) as well as 
dual multithreading (broken line); the utilizations of both processors are prac- 
tically identical because, in these particular cases, the memory is the system’s 
bottleneck that restricts the performance of other components. 
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Utilization improvement 




Fig. 9. The improvement of processor utilization due to dual block multithreading; It = 
10, tm = 10, t cs = 1, Pal = 0.2, p a2 = 0.1 



Processor utilization (1-2) 




number of available threads 

Fig. 10. A comparison of processor utilization; It = 10, t m — 20, t C s — 1, Psl — 

0 . 2 , p s2 = 0.1 



All presented results indicate that the number of available threads, required 
for improved performance of the processor, is quite small, and is not greater 
than 4 threads. Performance improvement due to a larger number of available 
threads is rather insignificant. 

Obtained processor utilization results are consistent with other studies of the 
performance of multithreaded architectures [16], [15]. The performance of dis- 
tributed memory multithreaded multiprocessor systems can be compared with 
the results presented in this paper by assuming that the probability of access- 
ing local nodes is equal to 1 (which means that the nodes can be analyzed in 
isolation). 

The presented models of multithreaded processors are quite simple, and for 
small values of modeling parameters (nt, n p , n s ) can be analyzed by the ex- 
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plorations of the state space. The following table compares some results for the 
standard block multithreaded processor: 



n t 


number 
of states 


analytical 

utilization 


simulated 

utilization 


1 


11 


0.417 


0.417 


2 


107 


0.591 


0.587 


3 


207 


0.642 


0.643 


4 


307 


0.658 


0.655 


5 


407 


0.664 


0.663 



For a dual block multithreaded processor the comparison is: 



n t 


number 
of states 


analytical 

utilization 


simulated 

utilization 


1 


11 


0.417 


0.417 


2 


130 


0.672 


0.670 


3 


320 


0.793 


0.793 


4 


642 


0.848 


0.841 


5 


972 


0.878 


0.883 



The simulation- based results are very similar to the analytical results ob- 
tained from the analysis of states and state transitions. It should not be sur- 
prising that for more complex models the state space can become quite large. 
For example, the state space for the dual multithreaded processor increases by 
more than 300 state for each additional thread (above 3). Analytical solution of 
very large systems of linear equations (which describe the stationary probabili- 
ties of states) may require special numerical techniques to provide the necessary 
accuracy. Therefore, discrete-event simulation of net models is an attractive 
alternative to exhaustive state space exploration of complex models. 

Finally, it should be noted that the presented model is oversimplified with 
respect to the probabilities of pipeline stalls and does not take into account the 
dependence of stall probabilities on the history of instruction issuing. In fact, the 
model is “pessimistic” in this regard, and the predicted performance, presented 
in the paper, is worse than the expected of real systems. On the other hand, the 
simplicity of the presented model is likely to outweight its simplification(s) as 
their effects are not expected to be significant. 
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Abstract. Resource brokering is an essential component in building effective 
Grid systems. The paper discusses the performance evaluation of a broker that 
is designed within the SNAP (Service Negotiation and Acquisition Protocol) 
framework and focuses on applications that require resources on demand. The 
performance evaluation is carried out using a combination of mathematical 
modelling and simulation. Initial results are presented, indicating that the 
simulation and modelling are in good agreement. 



1 Introduction 

The Grid offers scientists and engineering communities high performance 
computational resources in a seamless virtual organisation [1], These resources are 
diverse and heterogeneous in nature, spanning across multiple domains and are not 
owned or managed by a single administrator. 

A core component, which is desirable in order to insulate the user from the Grid 
middleware complexities, is a resource broker, which performs the task of mapping 
application requirements to resources that can meet those requirements. Specifically, 
brokering is defined as the process of making scheduling decisions involving 
resources over multiple administrative domains [2], This can include searching 
multiple administrative domains to use a single machine or scheduling a single job to 
use multiple resources at a single site or multiple sites. A Grid broker must be capable 
of making resource selection decisions in an environment where it has no control over 
the local resources, the resources are distributed, and information about these 
resources is often limited or stale. 

A key goal of Grid computing is to deliver utility of computation, as defined by 
users' Quality of Service (QoS) requirements. One approach to providing this 
functionality is to use SNAP (Service Negotiation and Acquisition Protocol) [3], 
SNAP provides a modular structure for managing the access process to and use of 
resources in a distributed heterogeneous environment such as the Grid. This protocol 
is an appropriate choice in the design and implementation of a user-centric broker, 
since it provides the means to negotiate and acquire resources that meet the user's 
application requirements through Service Level Agreements (SLAs) [3], Specifically, 
it defines a general framework within which resource acquisition, task submission and 
binding of task to resources can be carried out, as dictated by the ability of those 
resources to satisfy the needs of the user. 
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In [5] the authors discussed the implementation of a simple SNAP-based resource 
broker and a more sophisticated SNAP broker, following a three-phase commit 
protocol. It was shown that, when certain specific scenarios occur, the use of the 
three-phase commit protocol provides a performance enhancement over the simple 
SNAP broker, in terms of the time it takes for a job to be successfully submitted and 
begin execution. However, the likelihood that these scenarios occur under realistic job 
traffic conditions was not addressed experimentally. 

This paper presents an approach, based on mathematical modelling and simulation, 
to evaluating the performance of the SNAP resource brokers. This approach allows a 
wide range of possible traffic conditions to be considered. The traffic model on which 
the analysis is based is expressed using queueing theory [6], 

The paper is organised as follows. Section 2 describes the architecture and 
protocols for the simple and three-phase commit SNAP brokers. Section 3 discusses 
the traffic model, used to provide the framework for modelling and simulation. 
Section 4 discusses the mathematical modelling, followed by a description of the 
simulation in section 5. Experiments and results are presented and discussed in 
section 6, followed by conclusions and indications of future work in section 7. 



2 SNAP-Based Resource Brokers 

SNAP is motivated by the requirement, in a Grid environment, to reconcile the needs 
of the users with those of the resource providers. This section presents a SNAP broker 
architecture and the broker protocols considered in this research. Details of SNAP can 
be found in [3]. 

2.1 SNAP Broker Architecture 

Figure 1 shows the components that comprise the broker. In this architecture, the 
broker begins by parsing the user requirements submitted through a Grid portal. The 
second layer uses a Matchmaker, supplied with the parsed user requirements, to 
contact a Knowledge Bank (KB). The latter is a repository that stores static 
information on all resources. The broker can access this information on behalf of the 
user for each resource he/she is entitled to use. The information stored in the KB as 
attributes include the number of CPUs, the operating system, memory, storage 
capacity and past behaviour performance of a resource. This enables the broker to 
fdter out all resources that could handle the job's needs prior to contact with the MDS, 
thereby avoiding contacting resources, which are unable to support the user's 
application. Further discussion on this can be found in [5]. 

Referring to Figure 1, on receiving the information the Matchmaker forwards the 
details to the Decision Maker that evaluates the information and categorises the 
potential resources into two categories by tagging them as either blue or white. This 
corresponds to their significance, i.e. that some resources are more ‘desirable' (blue) 
than others (white). The issue of which attributes could be used to classify resources 
in this way is currently being addressed. 

The Resource Gatherer based on the information received from the Decision 
Maker queries the information provider on each selected resource to gather dynamic 
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information on their status. The Globus Monitoring and Directory Service [8] (MDS) 
is used in this architecture to gather dynamic information. 

Once all queries have reported back to the broker the information is forwarded to 
the Co-ordinator, which nominates the resources to handle the tasks and secures them 
for utilisation through the use of immediate reservation. Once the resources are 
secured the final procedure is executed by the Dispatcher by submitting the task and 
binding it to the resources. 

2.2 SNAP Broker Protocols 

The simple SNAP broker works according to the following protocol: 

1 . Having received the user requirements, the matchmaker contacts the knowledge 
bank, which returns the attributes for the resources the user has access to and 
that are capable of supporting the job. 

2. The matchmaker forwards the information to the decision maker, which 
prioritises resources, tagging them blue and white, corresponding to “high 
priority” and “adequate” respectively. 

3. The decision maker passes this information onto the resource gatherer. 

4. The resource gatherer contacts the MDS (the GRIS (Grid Resource Information 
Service) on each resource) to obtain up-to-date dynamic information about 
‘candidate' resources. In this step, probes are set up. This only occurs the first 
time step 4 is carried out. Probes do not need to be set up subsequently. These 
are only used in the simple SNAP broker, to support fast reservation of 
resources. 

5. The dynamic information about the resources is passed to the co-ordinator, 
which makes a decision as to where the job should run. If insufficient resources 
are available, the co-ordinator informs the resource gatherer and step 4 is 
repeated. Otherwise the co-ordinator reserves the chosen resources. If this is 
unsuccessful (e.g. because another user has taken one or more of the chosen 
resources), return to step 4. 




Fig. 1. A Grid resource broker architecture within the SNAP framework 
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Once resources have been secured, the simple SNAP broker can transfer any 
necessary data and submit the job for execution. However, as the following scenario 
illustrates, difficulties can arise in successfully securing resources. 

Having received a user's request to run an application and details of the job 
requirements, a resource broker probes various sites that encompass resources, which 
could cater for the user's request. At the point of receiving a response from all 
providers, the broker begins co-allocating the task based on the information gathered. 
However time has elapsed since their last confirmation and other candidates 
(unknown to the broker) may have committed to some or all the resources it decided 
to use. If this occurs prior to reservation, alternative resources must be identified to 
replace those that are no longer available. This process could repeat itself and could 
lead into an oscillation between the broker and the resources without a successful job 
submission. Even if the job is eventually submitted successfully, such a scenario 
could significantly delay the execution start time. Consequently, the three-phase 
commit protocol was designed in order to reduce the likelihood of such a problem 
arising. The protocol is based on the idea of providing the broker with a vision of the 
resources through the use of probes. Hence the resources inform the broker when their 
status changes rather than the broker needing to contact resources to determine their 
current status. This is discussed in more detail in [5], 

The three-phase commit broker works according to the following protocol (first 
three steps are as above): 

4. The resource gatherer contacts the MDS (the GRIS on each resource) to obtain 
up-to-date dynamic information about ‘candidate' resources. In this step, probes 
are set up. This only occurs the first time step 4 is carried out. Probes do not 
need to be set up subsequently. These probes listen for any changes in the status 
of resources. In addition they are used to support reservation. 

5. The dynamic information about the resources is passed to the co-ordinator. 

6. The co-ordinator makes a decision as to where the job should run. If 
insufficient resources are available, the co-ordinator waits until the probes 
inform it that sufficient resources are available to support the application. 

7. If any resources are taken by other users, the broker is made aware of this by 
the probes. If this occurs, step 6 is repeated. Otherwise the co-ordinator 
reserves the chosen resources. If this is unsuccessful, return to step 6. 

Once the resources are reserved, the dispatcher transfers any necessary files and 
submits the job. 



3 Traffic Model 

In order to model the behaviour of the SNAP-based resource brokers, a traffic model, 
which enables different realistic traffic conditions to be considered, is required. The 
approach taken here is based on queueing theory [6]. Initially a simple model was 
chosen, in order to enable a simple comparison between simulation and analytical 
results. This model is presented in section 3.1. The model was then extended to enable 
evaluation of the resource brokers under more realistic traffic conditions than was 
possible with the simple model. The extended model is presented in section 3.2. 
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3.1 Simple Traffic Model 

It is assumed that each (single CPU) resource is a server and has a corresponding 
single-server queue. The queue capacity is initially set to infinity. Jobs are 
independently submitted to each queue, with random inter-arrival and service times 
(i.e. each queue is an M/M/1 queue). The broker needs to secure resources and submit 
jobs within this environment. The model is depicted in Figure 2. 

The following parameters are used within this model: 

Number of Processors (Servers) P 

Mean Service Time T 

Mean Arrival Rate A 

Note that, with this model, the traffic on different resources does not display any 
correlation. Hence many realistic scenarios are not encapsulated by this model (e.g. 
users submitting jobs that require more than 1 resource). This is addressed in the 
extended model, discussed in the following section. 

3.2 Extended Traffic Model 

In order to account for correlations between traffic on different resources, a multi- 
server queue is introduced. As before, each server has an associated queue. However, 
incoming jobs to the system enter a multi-server queue. Each job has a service time 
( T ) and number of resources ( R ) required associated with it. There are a number of 

possibilities regarding how jobs at the front of the multi-server queue are dealt with. 
For example: 

Queues Resources 



Other users 



x 



*■ 
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Other users 



*• 



Other users 
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Fig. 2. Queueing system used in simple traffic model 
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Fig. 3. Queueing system used in extended traffic model 

1. When a job is at the front of the multi-server queue, it is sent to queues 
associated with those resources with the least items waiting in the local queue. 

2. When a job is at the front of the multi-server queue, it is sent to local queues 
corresponding to randomly chosen resources. 

3. When a job is at the front of the multi-server queues it is sent to local queues in 
a round-robin fashion, i.e. (for P resources) queue 1, queue 2, . . .queue P, queue 
1 ... 

The jobs arriving in the multi-server queue have random inter-arrival and service 
times, while the number of resources required for a particular job is chosen at random 
from the set {1,2,4,8,16,32}. This is illustrated in Fig. 3. 



4 Mathematical Modelling 

This section presents a mathematical analysis, carried out in order to provide 
expressions that enable the performance of the SNAP based brokers to be evaluated. 
Specifically, expressions are obtained, enabling the average time taken (for each 
broker) between receiving user requirements and the job being submitted for 
execution. This is carried out using the simple traffic model, presented in section 3.1. 
These results enable the simulation and analytical results to be compared. If the 
results from these two approaches agree, this provides evidence to support the validity 
of further simulation results based on the extended traffic model, where the analytic 
approach would be impractical. 

The following parameters are used in the analysis of the broker. The steps referred 
to are those given in section 2.3, where the SNAP broker protocols are presented. 

J: Number of resources required by the job submitted. 

t KB : The time taken for steps 1-3 of the broker protocols. 

t mds '■ The time taken for step 4 of the broker protocols. 

t dec • The time taken by the Co-ordinator to decide where the job should run. 

t res : The time it takes to reserve resources. 
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The time taken to submit the job once resources have been reserved is not included 
in the analysis, since it is not dependent on which of the protocols (discussed in 
section 2.3) is used. 

Section 4.1 presents the analysis for the simple SNAP broker and the 
corresponding analysis for the three-phase commit broker is given in section 4.2. 

4.1 Simple SNAP Broker 

Step 5 takes t dec + t res . It is assumed that 

t mds ^ mds( 1) 2) (1) 

Here t mds(l) is the time, for gathering resource information, during which any 
change to resource status (on any resource being contacted) will be picked up and 
t mds{ 2 ) * s *h e t * me during which changes to status will not be identified. 

The total time the broker takes, from receiving user requirements until resources 
are secured, in the absence of other traffic is, 

E (t simple {no traffic )) = t KB + t mds + t dec + t res (2) 

Note that the above time does not account for the possibility that certain steps may 
need to be repeated. Referring to the broker protocol, for step 5, there is an overhead 
associated with the possibility that step 4 needs to be repeated due to insufficient 
resources being available the first time the MDS is contacted. Each time this is carried 
out, the time taken is (t mds + t dec ) . Let the average time taken to complete this 

operation be E(t mds/dec ) . Note that 

E { t mds/dec)=n{t mds +t dec ) (3) 

Here, n is the mean number of times that there are insuffient resources available 
when the MDS is contacted. This means that (t mds + 1 dec ) must be replaced by 

E (tmds /dec ) in equation (2). 

There is an additional overhead associated with the possibility that a chosen 
resource is taken prior to successful reservation. In order to explain the effect of this 
overhead on equation (2), consider the following scenario. Suppose an event, A 
occurs, taking time T A . If the event fails, then it must be repeated until it succeeds. 
Let the probability that the event fails on a given trial be P f . In that case, the entire 
process takes an average time given by, 

n = 1 



( 4 ) 
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The summation in equation (4) is equal to \j[\ — P , ) . 



Hence, 



) — 




( 5 ) 



In the case under consideration, event A corresponds to contacting the MDS, 
making a decision as to where the job should run and reserving resources. The time 
taken ( T A ) is therefore {E{t mds/dec ')+t res ) . Failure is caused by one or more chosen 
resources being taken by other users, prior to the completion of reservation. For the 
simple traffic model, the probability that a resource that is free at time t 0 is still free 

at time Zj is e ^ where A is the mean arrival rate. Here the time interval At 
involved ranges from after the t mds(l) , when the MDS is contacted, until reservation is 
successfully completed. Hence, 

= tmds( 2 ) + t dec + Kes ( 6 ) 



Hence, the probability that one of the J resources chosen to run the job is taken 
prior to successful reservation is given by, 

Pfau^-e-^ ( 7 ) 

This leads to the following expression for the average time the simple broker takes 
from receiving the users' requirements until resources are successfully reserved. 

simple ) = t KB +e (Pfamds /dec) + Kes) (*0 



4.2 Three-Phase Commit Broker 



In the case of the three-phase commit broker, the MDS is contacted only once, since 
the probes are used to provide the broker with a vision of the resources. However, 
there is still an overhead associated with the possibility that other users could take 
resources prior to the successful completion of the decision as to where the job should 
run. Hence t dec is replaced with E{t declthree _ phase )- In addition, once the broker 
makes a decision, it may fail to successfully reserve resources, if another user takes 
one or more of the chosen resources, during the time interval t . Using the same 

reasoning as given above for the simple broker to calculate the effect of this overhead, 
leads to the following expression for the average time it takes the three-phase commit 
broker to successfully secure resources. 



P^ three— phase ) 



:t KB +t mds +e 



XJt,., 



(4 



dec! three-phase 



)+o 



( 9 ) 
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5 Simulation 

The discrete event simulation tool used in obtaining these results has been developed 
from scratch. This tool, written in Java, adopts the process interaction approach to 
discrete-event simulation. The resource broker objects (in the physical system) are 
represented by logical processes. Interactions among physical processes (events) are 
modelled by timestamped messages exchanged among the corresponding logical 
processes. The programs developed for the simulation are executed using the 
traditional sequential simulation protocol (Global Event List) [9]. 

The objectives of the simulation experiments are twofold: 1) an observation of the 
behaviour of the broker in terms of time to secure resources, and 2) a comparison 
between the analytical and simulation results. Specifically, the simulator can be used 
to consider a wide range of traffic conditions, using both the simple and extended 
traffic models presented in section 3. Experiments using the simple model can be used 
to assess the validity of the results through comparison with the analytical results. 
Experiments can then be carried out, using the extended traffic model, enabling the 
effect of correlation of traffic across resources to be evaluated. In each case, the 
performance of the three-phase commit broker relative to the simple SNAP broker is 
of significant interest. 



6 Experiments and Results 

This section presents the experiments designed to study the behaviour of the SNAP 
brokers under a range of traffic conditions. The approach taken is to compare analytic 
and simulation results, obtained using the simple traffic model. This is used to 
validate the results obtained using the simulator. A wider range of results will then be 
obtained through simulation using the extended traffic model. 

6.1 Experimental Parameters 

The following parameter values will be used in the experiments described below. 
These are based on values obtained on a Grid testbed, with machines connected over a 
local area network using 100Mbps fast Ethernet [5]. Some of these values would 
differ considerably in a geographically distributed Grid environment. In particular, the 
time taken to submit a job and the time taken to contact the MDS would typically be 
larger on average. In addition the time taken to contact the MDS may vary 
considerably across different machines and widely separated locations. The effect of 
this will be considered in future experiments. 

• Time taken to connect to knowledge bank: 0.268 sec. 

• Time taken to fdter out resources: 0.017sec. 

• Time taken for the broker to decide on resources to be contacted and tag them: 
0.003 sec. 

• Hence t KB = 0.288 5 . 
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• Contacting the MDS takes 8 sec on average. It is assumed that changes to 
resource status are picked up in the first 4 sec. Hence, t mds0) = t mds(2) =4 s 

• The time taken to decide on where to submit the job is 0.007 sec. Hence, 

tdec = °- 007 5 • 

• Reservation takes 2.881 sec. Hence, t res = 2.881 5 . 

6.2 Experimental Design 
6.2.1 Experiment 1 

In this experiment, the entire scenario, involving the broker submitting a job into the 
system using the simple traffic model, is considered. For the initial run, the mean 
service time and mean inter-arrival time are 300s and 350s. The total number of 
processors is 128. It is assumed that all 128 processors are appropriate for the job to 
be submitted by the broker. 

Firstly, simulation is used to obtain values for E(t mds/dec ) and E(t dec/three _ phase ) 

in the simple SNAP and three-phase commit brokers respectively. 

The average time each broker takes to submit the job is measured as a function of 
number of processors (1,2,3...) required by the job. 

The simulation and modelling results, for the simple SNAP and the three-phase 
commit broker are then compared. If good agreement is obtained between simulation 
and modelling then this will support the validity of future results, obtained through 
simulation, for experiment 2 discussed below. 



6.2.2 Experiment 2 



This experiment is closely related to experiment 1, except that the extended traffic 
model is used in place of the simple traffic model. The mean inter-arrival time to the 
multi-server queue is 



1 _ 350 R 
A ~ 128 



(10) 



Here R is the average number of resources required by the jobs being submitted 
to the multi-server queue. In this case, since R is randomly chosen from the set 

{1,2,4,8,16,32}, R is 10.5. The mean service time associated with these jobs is 300s. 



6.3 Experimental Results and Discussion 

The results for experiments 1 and 2 are presented in this section. Simulation results 
were obtained over 1000 runs, i.e. 1000 job submissions by the broker for each point 
in the plots presented below. 

Fig. 4. shows a comparison, for experiment 1, of the simulation results with the 
analytic results for both the simple SNAP and three-phase commit brokers. The 
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average time taken from receiving user requirements until resources are successfully 
reserved are plotted as a function of the number of resources required by the job. The 
average inter-arrival time is 350 seconds and the average service time is 300 seconds. 
As can be seen from the figures, the simulation and modelling show good agreement, 
with the only significant discrepancy occurring for the simple broker when 16 
resources are requested. 

In Figure 5, the same results are used to compare the performance of the three- 
phase commit and simple SNAP brokers. Both the simulation and the analytic results 
indicate that the three-phase commit broker protocol provides a significant 
performance enhancement, particularly as the number of resources increases to 12 or 
more. 

Results for experiment 2 have been obtained, using the random and round-robin 
approaches to distributed jobs with the extended traffic model, i.e. approaches 2 and 3 
discussed in section 3.2. Figure 6 shows these results, with mean inter-arrival time 
given by equation (10) and mean service time of 300s. The three-phase commit 
broker again outperforms the simple SNAP broker, although the performance 
enhancement is considerably less than that obtained in experiment 1, where the simple 
traffic model is used. The reasons for this are currently being investigated. 





Fig. 4. Simulation vs. modelling results, showing the average time the simple SNAP and three- 
phase commit brokers take to secure resources. The mean inter-arrival time and mean service 
time are 350s and 300s respectively 





—♦—Simple 

-■-Three-phase 

commit 



Fig. 5. Simulation and modelling results showing the average time the simple SNAP broker 
takes vs. the average time the three-phase commit broker takes to secure resources. The mean 
inter-arrival time and mean service time are 350s and 300s respectively 
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Fig. 6. Simulation results showing the average time the simple SNAP and three-phase commit 
brokers take secure resources when the extended traffic model is used. Results are shown for 
random selection and round-robin selection of local queues 

7 Conclusions and Future Work 

A simple SNAP broker and a strengthened three-phase commit protocol have been 
presented. An approach to evaluating the performance of these brokers, through 
modelling and simulation has been discussed. This is based on using a queueing 
theory to develop a traffic model. A simple traffic model has been used, in order to 
validate the simulation results through the use of mathematical modelling. The results 
for presented in this paper show good agreement between modelling and simulation. 
Results are also presented, comparing the performance of the simple SNAP broker 
and the three-phase commit broker in terms of the average time it takes to secure 
resources. The results indicate that the three-phase commit broker does provide a 
performance enhancement. The significance of this performance enhancement is to be 
investigated by considering a wider range of parameter values (e.g. varying inter- 
arrival and service times, number of resources in the system and time it takes to 
contact resources). In addition, more sophisticated traffic models are to be considered. 
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Abstract. IEEE 802.11 protocols are formally expressed using the tv- 
calculus process algebra and a performance evaluation process algebra. 
We first describe the handoff mechanism in wireless LANs, and then 
the IEEE 802.11 MAC, a medium access control mechanism which is 
a variant of CSMA/CA. A Away handshake mechanism of IEEE 802.11 
with fixed network topology is expressed using the 7r-calculus. The veri- 
fication process for the specified protocols is briefly described; Mobility 
Workbench and PEPA Workbench are used as software tools for verifi- 
cation. 



1 Introduction 

Wireless devices and applications are gradually becoming part of our daily lives. 
In order to achieve the goal of offering better communication services, and pro- 
vide universal connectivity to increasingly mobile users, it is important that 
a suitable standard for Wireless Local Area Networks (WLANs) be designed, and 
an approach to interconnect these WLANs to existing wired LANs be adopted. 
IEEE 802.11 is the wireless LAN standard, developed under IEEE project 802. 
It defines both medium access control and physical layers. In contrast to wired 
devices, in wireless network we cannot adopt medium access control schemes 
such as Carrier Sense Multiple Access with Collision Detection (CSMA/CD) in 
order to prevent simultaneous transmission on the channel. Instead, the IEEE 
802.11 standard uses the Carrier Sense Multiple Access with Collision Avoid- 
ance (CSMA/CA) mechanism for wireless networks. Formal models have been 
successfully employed to specify communication protocols and to verify their 
properties over the last two decades. A verification process can be viewed in two 
steps: specifying a protocol, which might result in a model, and verifying the 
properties of the protocol. A formal specification is the definition of an object, 
or a class of objects, using a description technique. Each defined object reflects 
a real world entity. It is important to precisely understand the basic concepts 
or construction elements from which the real world entities are composed. In 
this paper we concentrate on the process calculi and algebras for expressing the 
IEEE 802.11 protocols. 



M. Nunez et al. (Eds.): FORTE 2004 Workshops, LNCS 3236, pp. 233—247, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 



234 



K.N. Sridhar and Gabriel Ciobanu 



Process algebra is a formalism to specify the behavior of systems in a sys- 
tematic, precise, modular and hierarchical way. The basic building blocks are 
processes and channels. Process algebra is compositional, providing scalability 
by composing larger processes out of smaller ones. We refer to process alge- 
bras like CCS [8], 7r-calculus [8], Performance Evaluation Process Algebra [3] 
etc. The Calculus of Communicating Systems (CCS) was originally developed 
by Robin Milner in 1980, and supports the analysis of interacting processes. We 
can draw diagrams of the processes as circles, and the interactions between them 
as connecting lines. In CCS, the processes can die, or split into two, but new 
linkages cannot be created. By contrast, the 7r-calculus is able to create new 
links. The 7r-calculus generalizes CCS by transmitting names rather than values 
across send-receive channels, while preserving matching as the control structure 
for communication. Since variables may be channel names, computation can 
change the channel topology, and by this process mobility is supported. Mil- 
ner emphasized the importance of identifying the “elements of interaction” [7], 
and the 7r-calculus extends the general model of A-calculus [ I ] with interaction. 
Performance Evaluation Process Algebra (PEPA) is similar to CCS in several 
aspects [2]; the operators and their semantics are similar. However, PEPA differs 
from CCS by adding stochastic rates to the actions. 

The paper concentrates on the modelling of the handoff procedure from 
GSM and the CSMA/CA 4- way handshake mechanism of WI-FI protocol (IEEE 
802.11). The paper presents a description in the 7r-calculus of these mechanisms 
of the IEEE 802.11 protocols, and further provide a verification of the obtained 
specifications using the Mobility Workbench tool. The quantitative analysis is 
given by using the Performance Evaluation Process Algebra and exploiting the 
facilities of the PEPA Workbench tool. The outline of the paper is as follows: 
Section 2 provides an introduction to the 7r-calculus. Section 3 describes the pro- 
tocols and provides their 7r-calculus specifications. A brief introduction to the 
Mobility Workbench and verification aspects are presented in Section 4. Section 
5 presents the quantitative analysis using the Performance Evaluation Process 
Algebra (PEPA) specifications of the protocols, and PEPA Workbench to deter- 
mine the backoff-duration values and their corresponding collision probability. 
Section 6 presents the conclusion. 

2 7r-Calculus 

The 7r-calculus is a widely accepted model of interacting systems with dynami- 
cally evolving communication topology. It allows channels to be passed as data 
along other channels, and this introduces a channel mobility. An important fea- 
ture of the 7r-calculus is that mobility is expressed by the changing configuration 
and connectivity among processes. This mobility increases the expressive power 
enabling the description of many high-level concurrent features. The 7r-calculus 
has a simple semantics and a tractable algebraic theory. The computational 
world of the 7r-calculus contains just processes (also called agents) and channels 
(also called names or ports). It models networks in which messages are sent from 
one site to another site and may contain links to active processes, or to other 



Describing IEEE 802.11 Wireless Mechanisms 



235 



sites. The 7r-calculus is a general model of computation which takes interaction 
as a primitive. 



3 IEEE 802.11 Standard 

The basic responsibility of a Medium Access Control (MAC) protocol is to en- 
sure that all the end systems on a local area network cooperate. Ideally, it re- 
quires that only one station transmit at a time. In 1997, the IEEE adopted the 
first standard for wireless LANS (WLANs), namely IEEE Standard 802.11-1997 
[5]. This standard defines MAC and physical layers. The scope of this paper is 
limited to 802.11 MAC. IEEE 802.11 architecture is built around a Basic Ser- 
vice Set (BSS). A BSS is a set of stations that communicate one another with 
the same MAC protocol and compete for accessing the same shared wireless 
medium. IEEE 802.11 broadly works in two modes: Distributed Coordinated 
Function (DCF) and Point Coordinated Function (PCF). DCF is the basis of 
the CSMA/CA standard access mechanism. Similar to Ethernet, it checks to 
see that the medium is clear before transmitting. Nodes uses random backoff 
after each frame to avoid collision. PCF can be viewed as an optional extension 
to DCF. PCF provides contention- free services, and is restricted to infrastruc- 
ture networks. In the first part of this section we will concentrate on the PCF 
mode, and describe the handoff procedure using 7r-calculus. In PCF mode, Ac- 
cess Points (AP) act as a point coordinator. APs are also termed as Base Stations 
(BS). Each Mobile Node (MN) is controlled by a single AP at any given point 
of time, and AP could control more than one mobile nodes. We concentrate on 
the movement of a node from the control of one AP to another AP. 

3.1 IEEE 802.11 Handoff 

An AP broadcasts a beacon signal periodically: typically the period is around 
100ms. An MN scans the beacon signal and associates itself with the AP having 
the strongest beacon. The MN keeps track of the Received Signal Strength (RSS) 
of the beacons transmitted by the associated AP. When the RSS becomes weak, 
MN starts to scan for stronger beacons from neighboring APs. The scanning 
process can be either active or passive. In passive scanning, MN scans the bea- 
con signal and associates itself with the new AP. In active scanning, MN sends 
a probe request to a targeted set of APs that are capable of receiving its probe. 
Each AP that receives a probe replies with a probe response. The MN chooses 
the AP with the strongest beacon or probe response and sends a reassociation 
request to the new AP. The reassociation request contains information about 
MN and its old AP. In reply, the new AP sends a reassociation response that 
has information about bit rates, station ID, and other information needed to 
resume communication. Once the MN starts communicating with the new AP, 
the handoff process is accomplished. To clarify the distinction between beacons 
and probes, we describe them here: 

— AP broadcasts beacon periodically. In passive scanning, MN scans the beacon 
signal and associates itself with the AP with the strongest beacon. 
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Fig. 1 . Handoff Mechanism and corresponding Process Model 



— In active scanning, MN sends a probe request to a targeted set of APs 
that are capable of receiving its probe. Each AP that receives the probe 
responds with a probe response. MN chooses the AP with the strongest 
probe response. 

Model. For simplicity, we will consider the case of only one mobile node, and two 
access points. This allows us to concentrate on the essential features. Consider 
the model as depicted in Figure la. The system consists of following objects: one 
Active Access Point (AAP), one Passive Access Point (PAP), and one Mobile 
Node (MN). Though AAP and PAP are access points with similar features, the 
cycle of operations they perform are different. So, in our modelling we represent 
them as different processes. The link Distributed System (DS) connects the 
two access points. This link is fixed, in the sense that the name will not be 
transmitted as objects in communications; intuitively this is part of a stationary 
network. This is not accessible outside the system, so we consider it as local to 
the system. In addition, each access point has one mobile link m representing 
a radio channel. The AAP shares this m with the MN. This represents the fact 
that AAP uses its m to communicate with the MN, while the m in PAP is unused 
as yet. These m’s are local names in a process and movement of channel m from 
one process to another is considered. 

The mobile node, as explained earlier, carries out probing to detect access 
point, when it moves away from the current access point. This probing process 
can be either active or passive. In our process model, as shown in Figure lb, we 
will not get into exact details of the probing mechanism, we just have a process 
Probe. This process probes and obtains a channel for the process Comm , which 
carries out the communication process. These two process communicate via the 
channel /, which is local to MN. The Probe process, communicates with PAP 
(either by beacons or probe packets), carries out reassociation and passes the 
channel to Comm process which uses this to communicate with PAP. The hand- 
off process is better understood by considering the specification in the 7r-calculus 
and its corresponding MWB code. 

Let us consider the specification of each component, one by one. A mobile 
node is composed of two processes Comm and Probe. Comm communicates 
with AAP, over the channel m, and with Probe over the channel l. It receives 
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the channel in from the Probe process and continues to communicate over the 
received channel. 

d&f 

Comm(l,m,data,disassoc ) = m(data).Comm(l,m, data, disassoc) 

+1 ( mnew ) . m{disassoc ) 

. Comm(l , mnew , data , disassoc) 

When mobility occurs, the Probe process carries out the probing and determines 
a passive access point. Probe and PAP share the channel, which is also termed 
as to. This to is passed to the Comm process over the local channel l. We have 
used same term to at both the places to indicate that only one to exist at any 
given point of time, and the nodes are sharing the same to. 

d e f 

Probe{l,m, reassoc ) = m(reassoc).l(m).Probe(l,m, reassoc ) 

AAP receives data from MN and it might receive disassoc message at any time 
from the mobile node, when the node wants to disassociate itself from the AAP. 
When AAP receives disassoc message, it continues to behave as PAP. 

de f 

AAP(m, data, disassoc ) = m(c).([c = data]AAP(m., data, disassoc ) 

+ [c = disassoc]PAP(m, data, disassoc )) 

Here the construction [x = y\P + [x = z]Q is an extension with a matching 
operator of the 7r-calculus syntax presented in Section 2; it is similar to the 
usual “if-then-else” operator. The passive access point receives reassoc message 
from the Probe process of MN, and continues to behave as AAP. 

(Ig f 

P AP{m, data, disassoc) = m(reassoc).AAP(m, data, disassoc) 

We now compose these processes to form a complete system and visualize how 
the lrandoff occurs. We will combine the process Probe of MN and PAP as P, 
which communicates over the channel to. 

dcf 

P(m, data, disassoc, l, reassoc) = {ym)(Probe{l,m, reassoc) \ 

PAP(m , data , disassoc)) 

Similarly, we will combine Comm process of MN with AAP as process Q, which 
communicates over channel to. 

de f 

Q(l,m, data, disassoc) = ( am)(Comm(l,m,data,disassoc)\ 

AAP(m , data , disassoc)) 

Now, the complete system of handoff is the process P running in concurrent with 
process Q , where l is the local channel. The process P transfers the channel to 
to the process Q, and the state of access points get interchanged, from passive 
to active and vice versa. 
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Fig. 2. State Transition for Sender and Destination 




In this model we do not consider the communication between access points. The 
decision criteria involved in probing mechanism, which results in identifying 
available links, is also not considered. However, these aspects can be directly 
added into the current specification, with few modifications and will not affect 
the formal representation of the handoff process. 

3.2 DCF Mode: CSMA/CA 

In this part, we concentrate on the DCF mode of IEEE 802.11. This mode is 
based on Carrier Sense Multiple Access-Collision Avoidance (CSMA/CA). The 
handshake mechanism involved in CSMA/CA can be either 2- way or 4- way. 
Here we consider the 4-way handshake mechanism. This mechanism has three 
components: sender, destination, and medium. We first consider the transition 
system of these components. These transition systems are extensions to the one 
used in [6]. Later, the model is described considering the specification of each 
and every component, and their subcomponents. 

Transition System for Sender 

Consider the transition system for sender as shown in Figure 2a. A sender with 
a new data packet to transmit monitors the channel activity. If the channel is 
idle for a period of time equal to DCF InterFrame Space (typically 128 /xs), 
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it transmits a control packet. Before actually transmitting the packet the node 
waits for small period VLUN. In this scheme, two small control packets are 
exchanged: Request To Send (RTS) and Clear To Send (CTS) packets. This 
exchange occurs before the data transmission process begins. The RTS packet 
contains information about the length of the frame, whereas the CTS acts as an 
acknowledgement for RTS. The sender sends the RTS packet and waits for the 
CTS acknowledgement. If the timeout occurs, or the channel is sensed busy, the 
sender goes to back off procedure. If the CTS is received before the timeout, the 
sender waits for Short InterFrame Space (SIFS) time, and sends the data. The 
time taken to send a packet is nondeterministic, and the success of transmission 
depends on whether collision has occurred or not. 

DCF adopts an exponential backoff scheme. In this scheme, the sender first 
waits for the channel to be free for a period of DIFS, and sets its backoff value 
according to the random assignment backoff = RANDOM (be), where be is the 
backoff counter, which is updated (decremented by one) when the channel is idle 
for some standard duration (known as ASLOTTIME). However, if the channel 
is sensed busy in this slot, it waits until the channel is free, and then waits for 
DIFS before resuming its backoff procedure. When the backoff value reaches 0, 
the sender starts sending its packet. RANDOM (), is a uniformly distributed 
integer in [0, (aCWmin + l)2 bc — 1], where aCWmin is the initial value used 
(typically 15). The backoff process is highlighted in a dotted box in figure 2a. 
In our specification, we do not consider the timing aspects of the protocol. The 
state Startsense, covers both passive and active sense. The passive sense is 
described more in later subsections. 



Transition System for Destination 

Figure 2b shows the transition system for destination nodes. Each destination 
waits for an incoming packet. If the packet arrives correctly (event Lcorrect), 
then the destination waits for SIFS and subsequently sends either CTS packet 
or acknowledgement (ACK). CTS packet is sent in response to the RTS packet, 
whereas ACK is sent in response to the data packet. On the other hand, if the 
message arrives garbled (event Lcollide), the destination node remains idle. 



Transition System for Medium 

The medium can be viewed as a communication line, whose end points are sender 
and destination. The transition system is as shown in Figure 3. In this transi- 
tion system, we consider a medium with two senders and two destinations. This 
consideration is in accordance to our model which is explained in later subsec- 
tions. Each node has the capability of sensing the medium. The medium will 
be initially in a free state, i.e., it is available for transmissions. From this point, 
receipt of a RTS or data packet from sender-1 or sender-2, triggers the transition 
to received!) R_1 or received!) R_2 respectively. This RTS or data packet can either 
finish successfully and return the medium to Mediumdree state or collide with 
a transmission by another sender. Once a collision occurs, the medium enters into 
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Fig. 3. State Transition of Medium 



receive_DR_l_2 state, after which a collision event is sent to both the senders. 
This whole process can be viewed by considering the right-hand side of the state 
Medium_free in figure 3. The left-hand side of the state Medium_free of figure 3 
explains the exchange of CTS and ACKs. The medium at state Medium_free 
can receive either CTS or ACK and carry out successful transmission of the 
same. We note that the situations where two CTS and ACKs collide are not 
modelled in this automaton. This is because we assume that such collisions are 
not possible. 

Model. Now we are ready to specify the 4-way handshake mechanism of the 
802.11 protocol, considering the components whose transition systems were de- 
scribed previously. We consider two senders and two destinations communicating 
over a channel MEDIUM. The complete system is described in Figure 4a. 

Various components which constitute the handshake mechanism, and the way 
these components communicate with each other can be viewed as shown in the 
process model: Figure 4b. The functionalities are explained by considering each 
and every process. 



The 7r-Calculus Expressions for the 802.11 Protocol 

1. Sender 

The sender process is broken into three sub-processes: SenderSense, Sender- 
Transmit and PassiveSense. This definition of sender is the same for both 
Sender 1 and Sender2. SenderSense queries the PassiveSense via channel 
psense and receives either true or false as a result. If it is true, it continues 
to query the medium. If the medium returns true for the query, it continues 
to behave as Sender Transmit. If any query results in false, then it continues 
to behave as SenderSense. 

We abbreviate SenderSense (psense, pctrl, sense, free, true, fals,cfre,ctru,cfls) 
and 

Sender Transmit (psense, pctrl, control, data, sense, free, true, fals,cfre,ctru, 
cfls, tran, coll, mesg,rts,dcts) 
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(a) System Model for (b) Process Model for CSMA/CA 

CSMA/CA 



Fig. 4. System and Process Model for CSMA/CA 

Sender Sense(psense , . . .) d = psense(free).psense(pres). 

( [pres = fals]SenderSense(psense , . . .) 

+[pres = true]sense{cfre) .sense(cres) . 

{{ores = cfls\SenderSense(psense , . . .) 

+[cres = ctru]SenderTransmit(psense , . . .))) 

Sender Transmit is the sub-process which handles the transmission part. This 
includes RTS/CTS, data and acknowledge exchanges. It communicates with 
the medium over two channels, control and data. Over the channel control 
it transmits RTS packets and receives either CTS packet or collision signal. 
Whereas, over data channel it transmits data packets and receives acknowl- 
edgement packets. 

SenderTransmit(psense , . . .) = control(rts}.control(tran). 

([ tran = coll]SenderSense(psense , . . . ) 

+[tran = dcts\data{mesg) . 
data(dack).SenderSense(psense , . . .)) 

PassiveS ense(psense, pctrl) subprocess receives the query from the Sender- 
Sense, and responds either true or false. 

PassiveSense(psense , . . .) d = psense(free) .psense{true) . 

PassiveSense(psense , . . .) 

+psense(free) .psense(fals) . 
PassiveSense{psense, . . .) 
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We compose the above subprocess into a single process called SenderCom- 
plete. 

SenderComplete(psense , . . .) d = vpsense(Sender Sense(psense , . . .) 

\PassiveSense(psense , . . .)) 

It is very important to note that in our definition of sender, we did not 
consider the backoff procedure. This helps us to concentrate only on the 
handshake mechanism, in which we are interested. Also, to include a backoff 
procedure we need the support of timers in 7r-calculus, which we consider in 
the next section. Passive sensing is another mechanism details of which are 
not considered. 

2. Medium 

The process Medium, is a little more complicated when compared to other 
processes. It communicates with both sender and destination. The defi- 
nition below considers two senders and destinations. It shares channels, 
sense, control, and data with sender, and channels, dcontorl , and ddata with 
destination. The suffixes 1 and 2 refer to sender variables 1, 2 and destination 
variables 1, 2. We abbreviate 

M edium(sensel, sense 2, controll, control2 

, data 1, data2, dcontroll, dcontrol2, ddata 1, ddata2) 

d e f 

Medium(sensel , . . .) = sensel(cfrel).(sensel(ctrul}.Medium(sensel , . . .) 

+sensel(cflsl) .Medium(sensel , . . .)) 
+sense2(cfre2).(sense2{ctru2).A4edium(sensel , . . .) 
+sense2(cfls2) .Medium(sensel , . . .)) 

-I -control l(rtsl) .(dcontrol l(rtsl) 
+control2(rts2).controll{colll) .control2(coll2) . 
Medium{sensel , . . .)) 

+control2(rts2).(dcontrol2(rts2) 
+controll(rtsl).controll(colll) .control2(coll2) . 
Medium(sensel , . . .)) 

+ dcontrol l(dctsl) .control 1 (dets 1) . 

datal(mesgl) .ddatal{mesgl) . 

ddatal(dackl) .datal(dackl) .A4 edium(sensel , . . .) 

+dcontrol2(dcts2).control2(dcts2). 

dat.a2(mesg2) ,ddata2(mesg2) . 

ddata2(dack2) ,data2(dack2) ,A4 edium(sensel , . . .) 

3. Destination 

Destination(dcontrol , ddata) is the simplest of all processes. It communi- 
cates only with process Medium via dcontrol and ddata. Like sender, the 
definition of destination is the same for both destination 1 and destination 2. 

d e f 

Destination(dcontrol , . . .) = dcontrol (dr ts) .dcontrol(dcts) . 

Destination(dcontrol , . . .) 

+ddata(mesg) .ddata(dack) . 

Destination(dcontrol , . . .) 
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4. Complete System 

Once all the components are defined, we are now ready to define the complete 
system termed as 

Mac(sense 1, sense 2, control 1, control2, datal, data2, dcontroll, 
dcontrol2, ddatal, ddata2, psense2, pctrl2, psensel, pctrll) 

This is the combination of sender, medium and destination. The channels, 
sense , control , data , dcontrol and ddata are local to Mac. 

def 

Mac(sense 1...) = usensel,controll,datal,dcontroll,ddatal, 
sense 2, control2, data2, dcontrol2, ddata2 
( SenderC ompletel(psensel , . . .) 

\SenderComplete2(psense2 , . . .) 

\Medium(sensel , . . .) 

\Destinationl(dcontroll , . . .) 

\Destination2(dcontrol2 , . . .)) 

4 Verification 

Verification of software may be viewed as the process of checking some prop- 
erty P against either the software, or a model Ai of the software. For software 
in general, this is a hard problem, as the verification process may involve in-depth 
reasoning, perhaps requiring theorem provers to confirm parts of the verification. 
In this section we focus on a verification tool for the 7r-calculus, emphasizing on 
the bisimulation equivalences and properties as deadlocks. 



Mobility Workbench (MWB) is a model checking tool for manipulating and 
analyzing mobile concurrent systems described in the 7r-calculus. It was devel- 
oped by B. Victor, F.Moller, L-H. Eriksson and M.Dam [10]. It is written in Stan- 
dard ML, and currently runs under the New Jersey SML compiler. An important 
functionality of the MWB is to decide the strong and weak open bisimilarity be- 
tween two systems described as agents, as well as checking deadlocks and other 
properties of the agents (expressed as /Lt-calculus formulas). 

In our work, we use this tool to carry out verification process. The 7r-calculus 
specifications of handoff process, and CSMA/CA 4-way handshake mechanism, 
which was described in the previous sections, was translated to MWB code. The 
syntax of MWB code is similar to that of the 7r-calculus, except for the fact that 
m(data) is written 'm{data). The handoff process is verified by stepping through 
the described agents. This stepping process allows the used to examine the state 
transitions. However, for CSMA/CA 4-way handshake mechanism we first verify 
properties such as deadlocks. The described system resulted in total size of 460 
states and with deadlock free. We also carried out experiments for observational 
equivalence in which we show the equivalence of the described system with an 
ideal system, a system without any collisions and failures. 
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5 Quantitative Analysis 

Performance Evaluation Process Algebra (PEPA) is similar to CCS in several 
aspects [2]; the operators and their semantics are similar. However, PEPA differs 
from CCS by adding rates to the actions. Each action has associated a stochastic 
delay which decides when an action takes place. With this addition of a stochastic 
delay, PEPA belongs to the class of stochastic process algebras. Syntactically, 
the composition symbol j of CCS is replaced by tx in PEPA; this new symbol 
is associated with a set of interacting ports. An action a of CCS is replaced 
in PEPA with ( a,R ), where R is the rate (delay) associated to a. The model 
generated by PEPA is a (continuous-time) Markov chain. The analysis of PEPA 
model consists of solving the probabilities of the states of the Markov chain. 

PEPA Workbench is a software tool developed at the University of Edin- 
burgh [9]. More information on the syntax used in PEPA Workbench can be 
found in [3]. PEPA Workbench is implemented in Standard ML, same as other 
workbenches like Concurrency Workbench and Mobility Workbench. A JAVA 
version of PEPA workbench is also available. We have used the JAVA version of 
PEPA workbench (TABASCO release). 

First step in a performance analysis is to derive the model of the system under 
study using PEPA language. This model is loaded into PEPA workbench, and 
state space of the model is derived. Next step developed. This is a mandatory step 
to carry out state-based analysis. The last step is to carry out actual analysis 
using accompanying tools such as PEPA state finder, and PML M [4]. PEPA 
model for IEEE 802.11 is as shown in Table 1. The components of the model 
are similar to earlier model; two senders and receivers and a medium. The rate 
values indicating timeouts: ctsto and datato are set to 1. DIFS and SIFS are set 
to 2 and 1, respectively, and NAV value is set to 10. An important rate value 
to the analysis is the backoff duration. We vary this duration to carry out our 
analysis. For the sake of simplicity, we do not change this duration dynamically 
after every successful transmission. However according to IEEE 802.11 standard 
this duration depends on the transmission history. The specification given in 
Table 1 follows the syntax of PEPA Workbench. 

The specification is loaded into the PEPA workbench and the corresponding 
state space is derived. The following steps are executed and confirmed: Parse 
successful. Exploring State Space. Number of States: 141. Calculating Transi- 
tions. Number of Transitions: 210. Approximate time to complete the derivation 
of the state space: 0.27sec. 

The results show that there are no deadlocking states, and no zero 
or infinite-rate actions. The generated state space has 141 states and 210 
transitions. As a consequence of these steps, the system generates three 
text files: filename . table, filename .hash, filename .maple. States of the 
model are associated with numbers, and they have associated a state 
table (filename . table), and a hash table (filename .hash). Using the 
filename .maple, the analysis can be carried out using a Maple tool. This can 
be used to solve steady state solutions corresponding to the underlying Markov 
chain. We have selected the linear Biconjugate Gradient method from the solvers 
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options of the PEPA Workbench to derive the steady state solution. This results 
in the steady state probability values for all the states derived, and the values 
are stored in f ilename . steadystates. 

5.1 State-Based Analysis 

With the rate information associated with actions, we can see how long the sys- 
tem stays in each state and performing the actions. We use PEPA state finder 

Table 1. PEPA Workbench description 

retry=1.0; difs = 2.0; ctsto = 1.0; datato = 1.0; 
sifs = 1.0; delay = 1.0; nav = 10; backoff-duration = 16; 

//SENDER- 1 

senderlO = (gm, dif s) . senderll ; senderll = (rtsl ,nav) . senderl2 ; 
sender 12 = (cl , inf ty) . sender 13 + (colli, infty) . sender 14; 
sender 13 = (datal, sif s) . senderl5 ; 
sender 14 = (rtsl, backoff-duration) . senderl6; 
sender 15 = (al , inf ty) . senderlO ; 

senderl6 = (cl , inf ty) . sender 13 + (colli, infty). senderll; 

//SENDER-2 

sender20 = (gm, dif s) . sender21 ; sender21 = (rts2 ,nav) . sender22 ; 
sender22 = (c2 , inf ty) . sender23 + (coll2, infty). sender24; 
sender23 = (data2 , sif s) . sender25; 
sender24 = (rts2, backoff-duration) . sender26 ; 
sender25 = (a2 , inf ty) . sender20 ; 

sender26 = (c2 , inf ty) . sender23 + (coll2, infty) . sender21 ; 

//RECEIVER-1 

recvlO = (rl , infty) . recvll ; recvll = (ctsl , sif s) .recvl2 ; 
recvl2 = (dl, datato) ,recvl3; recvl3 = (ackl , sif s) . recvlO ; 

//RECEIVER-2 

recv20 = (r2, infty) . recv21 ; recv21 = (cts2,sifs) .recv22; 
recv22 = (d2, datato) ,recv23; recv23 = (ack2 , sif s) . recv20 ; 

//MEDIUM 

mediumO = (rtsl , infty) .mediuml + (ctsl , infty) .medium2 + 

+ (datal , infty) .medium3+(ackl , infty) .medium4+(rts2 , infty) .medium5 + 

+ (cts2 , infty) .medium6+(data2 , infty) .medium7+(ack2 , infty) .medium8 ; 
mediuml = (rl , delay) .mediumO + (rts2 , infty) .medium9 ; 
medium2 = (cl , delay) .mediumO ; medium3 = (dl .delay) .mediumO ; 
medium4 = (al .delay) .mediumO ; 

medium5 = (r2, delay) .mediumO + (rtsl, infty) .medium9 ; 
medium6 = (c2, delay) .mediumO; medium7 = (d2, delay) .mediumO; 
medium8 = (a2, delay) .mediumO; medium9 = (colli .delay) . (coll2 , 
delay) .mediumO; 

//COMPLETE SYSTEM 

recvlO <rl ,dl , ctsl ,ackl> (senderlO <rtsl, datal, cl, al,colll> 
mediumO <rts2, data2, c2, a2,coll2> sender20) <r2,d2,cts2,ack2> 
recv20 
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Table 2. Collision probability with varying backoff-duration values 



Backoff-duration 


Pcoll 


8 


0.117 


16 


0.147 


24 


0.161 


32 


0.170 



tool provided with PEPA Workbench in order to carry out state-based analysis. 
This allows us to find the steady state probability associated with either a single 
state, or a set of states specified by a pattern (regular expression). The state 
finder matches the pattern, and then sums the probabilities of the fitting states. 
So, it is important to solve state values before carrying out analysis of single 
states. For example, in our work we carry out two simple quantitative analysis 
using the PEPA state finder tool. First we see the total probability value of 
Medium going into the state of collision (state medium9 from the above defined 
model). We term this value of collision probability ( P co ii )• We write a regular 
expression which matches any state in which medium is in medium 9. The reg- 
ular expression can be easily written in PEPA state finder, using which 

denotes a wild-card and will match any of the derivatives. For this example, the 
regular expression; ** < rtsl, cl, datal, colli, al, > medium 9 * * would suffice. 
The obtained value of result with backoff-duration set to 16 is 0.147. Next we 
vary the backoff-duration value and see the effect of this value on the collision 
probability:P co z;. Table 2 presents this result. 

Such an analysis is useful in studying the effect of parameters on the perfor- 
mance of the communication protocol, and finding optimal values for effects of 
any parameter. For example, in our analysis we study the effect of the backoff- 
duration parameter on the collision probability metric, and it helps in finding 
an optimal value for this parameter. From the above analysis, if the backoff- 
duration is not changing dynamically, it can be seen that for higher values of 
backoff-duration the collision probability is also high. So the backoff-duration 
should be less to have less probability of collision. These kind of studies can 
be carried out to decide on optimal values for the parameters. More detailed 
analysis using other PEPA tools can be carried out. 

6 Conclusion 

The application of formal methods to the verification of protocol properties is 
an interesting research area. We have described some of the IEEE 802.11 mecha- 
nisms using few process algebras. We have considered the handoff mechanism in 
wireless LANs and the MAC mechanism. We have provided a refinement of the n- 
calculus specification with timers. Then we have used the Mobility Workbench to 
make simple verifications on the specified system. Finally, we did a quantitative 
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analysis using a performance evaluation process algebra. The backoff procedure 
and timing aspects are considered with PEPA modelling and PEPA Workbench. 
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Abstract. In replicated transactional systems, lazy update protocols 
have exhibited an undesirable behaviour, due to an increased abortion 
rate in scenarios with high degrees of access conflicts. In this paper, 
the abortion rate problem is studied from a statistical point of view. 
The resulting expressions describe the abortion problem, and were used 
to design a hybrid update database replication protocol, with perfor- 
mance similar to traditional lazy update protocols but with lower abor- 
tion rates. The protocol’s algorithm has been validated analytically. Once 
implemented, performance measurements have confirmed the predicted 
results. 



1 Introduction 

Replicated transactional systems have a wide range of applications where it is 
often convenient or even necessary to replicate the information in a set of servers, 
each one attending its local clients. Replicas must then be interconnected, usu- 
ally via a WAN. Moreover, a predominant locality of access patterns typically 
suggests a partitioning of the database [1, 2]. Replicated transactional systems 
enable a high degree of availability, as needed by many 24/7 services for network- 
internal or external clients. Efficiency and high availability of such services are 
key to their acceptance and success. 

The MADIS project [3] provides a solution for database applications fitting 
the characteristics outlined above. Its architecture provides access to replicated 
databases, together with a standard API and a set of consistency protocols that 
maintain the coherence of the replicated data. Examples of these protocols were 
presented in [4, 5, 6], using different approaches for the update propagation. 

When developing some protocols destined to cater for a high degree of data 
locality, we encountered that some applications’ needs could be satisfied with lazy 
update protocols [2]. These protocols have a short transaction service time, but 
a high abortion rate, and replicas may become inconsistent due to lazy update 
propagation. To understand the problem, we performed a statistical study of the 
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C02-01. 



M. Nunez et al. (Eds.): FORTE 2004 Workshops, LNCS 3236, pp. 248—261, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 



An Analytical Design of a Practical Replication Protocol 249 



abortion rates obtaining a parametrized expression describing the behaviour. 
The use of the expression as an oracle to predict the freshness state of each 
accessed object allowed us to theoretically determine an improved basic lazy 
protocol. Theoretical analysis predicted that the protocol should yield, at low 
performance costs, a reduction on the abortion rates. The protocol includes the 
run-time computation of that expression, which can also be used to decrease 
the outdate time of replicated objects. Experimental validation of the predicted 
behaviour resulted in a modification of the protocol, to find dynamically its 
optimal tuning. 

Section 2 includes the description of the modeled system and the results 
of the formal analysis of the abortion rate. Section 3 describes the proposed 
algorithm, together with a theoretical analysis for determining the achievable 
improvements. Section 4 describes the modification performed to automate the 
optimal tuning of the algorithm. Section 5 addresses related work, and section 6 
conclusively summarizes the proposed protocol. 



2 Modeling the Abortion Rate 

The MADIS middleware provides transparent access to networked relational 
DBMSs, as if it were a single database. Thus, clients of each node are enabled 
by MADIS to access the data locally. A consistency protocol, plugged into each 
node, is in charge of propagating all local updates to all other database replicas. 

2.1 The Modeled System 

One of the problems solved by MADIS [7] is to ensure the consistency of trans- 
actions being executed in different database replicas. Depending on the needs of 
an application, different update propagation policies are conceivable. Different 
protocol modules which implement such policies can be plugged into MADIS, 
thus enabling the MADIS system administrator to suitably choose and exchange 
the consistency protocol at will. 

One of our target applications was that used by medium-size enterprises with 
geographically distributed business units. Each enterprise’s database is supposed 
to embody a common information repository to the entire company, while taking 
into account that each work unit may have a particular access pattern of its 
own: each one has write access to particular ’’regions” of the database, while 
only reading the information written or updated by other units. 

This kind of scenarios typically requires high availability of data, which 
usually is achieved by replicating the entire database in each network node. 
The replication protocols traditionally deployed in such scenarios use optimistic 
consistency control , in order to avoid distributed deadlocks. Due to its opti- 
mistic policy, such protocols prevent any locking of objects whenever they are 
locally accessed. Thus, for maintaining consistency of replicated data, some kind 
of ’’versioning” (or ’’timestamping”) in the database objects becomes neces- 
sary. At commit time, versions are compared, and inconsistent transactions are 
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aborted. Committing transactions must then propagate their changes to the 
rest of nodes. When the propagation is completed within the commit phase, it is 
known as eager update propagation. 

Now, due to the locality of its access patterns, our target environment turned 
out to be suitable for lazy update propagation protocols. In contrast to the eager 
ones, these protocols do not complete the propagation during the commit. Thus, 
the changes performed by a locally committed transaction can not be completely 
propagated to the rest of nodes, where other transactions might access out-of- 
date information, leading also to their abortion. 



Computable Parameters. As the database is fully replicated, the number of 
stored objects, say N, is essentially the same for each node. 

For each node NODEk (k = 1..K, for K nodes in the system), it is possible 
to compute a number of variables: 

— nwk The mean of objects written per write-transaction committed in the 
system at NODE 

— wtpsk The number of write-transactions committed per second at NODE 



2.2 Abortion Rate Analysis 

To understand the abortion problem, we proceed to analytically determine the 
reasons by which a transaction is aborted. To this end, we use statistical tech- 
niques to formalize the behaviour of optimistic lazy protocols. Thus, the abortion 
probability for a transaction S is PA(S) = 1 — ( PC conc (S ) • PC out d{S)) where: 

— PC conc {S) is the probability that the transaction concludes without concur- 
rency conflicts. 

— PCoutd(S) is the probability that the transaction concludes without access- 
ing to outdated objects. 

For predicting the behaviour of our algorithms, particularly their abortion 
rate, it is useful to focus attention on the value of PC out d{S). This probability 
can be computed in terms of the probability of a transaction to conclude with 
conflicts produced by the access to outdated objects, PA out d(S). 

Our results indicated that each access in a transaction can lead to its abortion 
with probability 



P A ou td(Oi') 



1-(1 



T.k™k xY, k wtps k xS(oi) 

n) 



(1) 



where <5(oj) is the local time for which the object Oj has not been updated in the 
executing node. 

This expression, computable with only a few parameters, permits to compute 
the probability for an object access to cause the abortion of the transaction by an 
out-of-date access. A transaction commits when none of its object accesses causes 
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its abortion: PC out d(S) = PC out d(o{) x ... x PC out d(o na pt ) This is equivalent to: 



PC outd (S) = (1 



1 \ nwwtxwtpsx (<5(oi)+<5(o2) + ...+£(o na 

n) 



( 2 ) 



Only nwk and wtpsk must be collected in the system nodes for obtaining the 
expression ( nwwt = ^^2 k nwk and wtps = Yhk w ^P s ^)- addition, 8{oi ) can 
be locally maintained as metadata, similar to version numbers or timestamps. 

The results, although not amazing, serve to understand the main relevance of 
the different parameters in the problem: N, nwwt , wtps , and 8(oi). We observed 
that 5(pi) is the unique parameter depending on the protocol, since the rest of 
parameters are inherent to the system. Thus, theoretical analysis guided us to 
design a lazy propagation algorithm reducing 5{ot) to improve the abortion rate. 



2.3 Preliminary Validation of the Model 

We have validated the algorithm presented above by implementing a simulation 
of the system. In this simulation, we have implemented nodes that concurrently 
serve transactions, accessing different objects of a distributed database. We have 
also modeled the concurrency control and a basic lazy update propagation pro- 
tocol. 



Assumptions. For a preliminary validation of the expression, we performed 
an implementation of a simulation [8, 9, 10] following a number of assumptions 
compatible with the ones taken for the model computation. We implemented an 
optimistic lazy protocol in the simulation. The following load parameter values 
were set: 

• The system has 4 nodes, each holding a full replica of the database, contain- 
ing the experimental amount of 20 objects, since a small database maximises 
the probability of access conflicts. 

• For each object, a local replica held its value and the version corresponding 
to its last modification. 

• Three kinds of transactions have been considered, with a probability of 0.2, 
0.4 and 0.4 to occur, respectively: 

• ’’Type 0” transactions, that read three objects. 

• ’’Type 1” transactions, that read three objects, and then write all of 
them. 

• ’’Type 2” transactions, that read six objects, and then write three of 
them. 

• The model supports the locality of accesses by means of the probability 
for each accessed object to be managed by its processing node. For type- 
0 transactions, locality is set to 1/4. For type-1 and type-2 transactions, 
locality is set to 3/4. 

• The simulation time has been set to discard the simulation stabilisation time. 
This allowed to scale up to 60,000 transactions. 
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Completeness of the prediction 




PA_outd 



Fig. 1. Evolution of the inaccuracy for different P [update] 



Accuracy of the Prediction. In the simulation, we computed the value for 
the expression at each object access for each started transaction. With this in- 
formation, a histogram was elaborated holding the computed probability for an 
object to be out-of-date. For each object, we also built a parallel histogram hold- 
ing the actual number of objects with an out-of-date value. Thus, the histogram 
contained 100 cells, each one representing a discrete value of the expression for 
PA ou td(oi) : and containing the number of objects with an out-of-date value. At 
the end of each experiment, the values of the cells were divided by the total 
number of accesses performed in the simulation, providing the actual ratio of 
stale accesses for each expression value. 

Figure 1 shows the evolution of the correlation between the values of the 
expression and the actual abortion rate experimentally obtained. 

The optimum line is also shown, corresponding to the diagonal. The more 
accurate the prediction is, the closer the curves are. The studied prediction 
differed from the ideal line with a lower bound pattern. As can be seen, it is 
quite close to the ideal. 

3 Design of the Improved Algorithm 

The expression obtained statistically evidenced that the clue to improve the 
abortion rate of lazy update protocols consisted in the reduction of the outdate 
time of the local replicas of each object (i.e. S(oi)). Consequently, the next step 
consisted in determining the improvement achievable by the reduction of that 
outdate time. 
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Probability for an transaction (nr=1) to 

(a) nr=l 



Probability for an transaction (nr=4) to succeed 

(b) nr=4 



Fig. 2. Evolution of the improvement varying A 



3.1 Theoretical Boundary of an Improvement 

This step, based on the computation of the serial analysis of the basic expression 
for PA^Oi), yielded an expression describing, in terms of a single variable A, the 
increase of the success probability for each object accessed by a transaction: 

?g_ = p C PCx(A- 1) ) where A = (3) 

From this expression we obtained that the improvement of the probability for 
an object to be accessed in an adequate way (i.e. not a stale access), is deter- 
mined by pfj, and that it benefits from the decrease of the value of A, which 
determines the existing relation between d' T (the duration of the transactions on 
the modified protocol) and S (the outdate time on the original protocol). This 
study also brought out the straightforward relation between d' T and Pjjpd (i.e. 
the probability for an object access to cause an update) . 

The described expression was used to determine a number of curves of im- 
provement. These curves were used to graphically represent the achievable in- 
crease of the probability of commit for different types of transactions. 

For example, for the most simple transaction, performing a single read ac- 
cess, we established as a parameter the probability for a requested object to be 
previously updated (i.e. Pjjpd ), and then studied the achieved improvement for 
different values of A (and, consequently, different computational overheads). 

Figure 2(a) shows the commit probability for a session accessing only one 
object. It shows how the commit probability can be improved, when the update- 
time is decreased to one half, up to 120% of the original commit chance. When 
the update-time is decreased by a tenth, the improvement reaches 140%. Lower 
values of A provide marginal improvements, at higher computational costs. 

When more than just one object is accessed in a transaction (figure 2(b)), 
the results showed higher differences between the commit promises, due to the 
factorisation of such probabilities. These results pointed to the convenience to 
apply techniques based on the reduction of the outdate time, in scenarios with 
parameters as described above. 
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3.2 The Improved Algorithm 

In a lazy update propagation protocol, the outdate time of the object replicas 
held by a particular node depends on the time the object is locally accessed. 
Objects are updated when a local transaction accesses them in write mode, and 
the transaction is finally committed. Another situation producing the update of 
an object arises when a transaction aborts at commit time due to a stale access 
over this particular object. 

To reduce the abortion rate, it becomes necessary to decrease the mean out- 
date time (represented in the expressions by 8). We observed that this can be 
achieved by either a push (i.e., initiated by an update-propagator replica) or 
a pull model (i.e., initiated by a reader replica, which perhaps has an outdated 
state). This can be done periodically or on request (i.e., when the object is 
updated in the push model, or when the object is read in the pull model). 

Periodical push execution has the disadvantage of requiring a huge amount 
of memory, because it needs to manage the S(oi) for each object not totally 
propagated. On the other hand, periodical pull execution needs to periodically 
perform a query in order to retrieve a list of objects suitable to be updated, 
using the metadata (<5). 

In contrast, we observed that the implementation of on request actions at 
each node required little memory usage. Moreover, additional metadata (i.e. 
8(oi)) may be used, introducing only a marginal overhead. 

The main disadvantage of the push model is that it may introduce unneeded 
propagations, in case there are no explicit requests to which the propagation 
responds. As a result, the performance of the system may degrade. On the other 
hand, the pull model may require a lot of interaction with the different nodes in 
the system. However, this disadvantage is not dramatical in systems with high 
locality of accesses. Consequently, we designed an algorithm based on the pull 
model, to reduce the outdate time of the replicated objects. 

Its basic principle consists in using the computed theoretical expression for 
estimating the likelihood of an object to be locally updated before being accessed 
by a session. This estimation, performed with a certain degree of accuracy, de- 
pending on the “freshness” of the values of nwk and wtpsk the node has, was 
used as an oracle in our algorithm. The precise use of the expression and an ad- 
equate mechanism for the propagation of these parameters has been presented 
in [6], 



Algorithm Outline. The COLU (Cautious Optimistic Lazy Update) consis- 
tency protocol multicasts object updates to the asynchronous nodes, once the 
transaction completes its commit phase. Consistency conflicts among transac- 
tions are resolved with an optimistic approach, using object versions and check- 
ing them during the commit phase. Thus, object accesses are allowed along the 
transaction execution without any locking. 

As seen, the main inconvenience of this Lazy Update Propagation is the 
increase of the abortion rate. The COLU protocol makes use of the expression 
for the probability of an object to cause the abortion of a transaction, to predict 
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the convenience for a transaction to ensure that an asynchronously updated 
object has a recent version in the local database. 

In order to apply these results, a threshold of PA(oi) (i.e. , the abort probabil- 
ity of an access to Oi due to a stale access) needs to be established, for considering 
the object as “convenient to be updated”. An adequate value for this threshold 
is supposed to minimise the number of abortions caused by accesses to out- 
dated objects, keeping low the number of updates for the system. Thus, when a 
transaction requests an object access, PA(oi) is computed and compared with 
the threshold. As a result, the algorithm obtains an updated version for objects 
predicted to be stale. 

The implementation of this principle introduces a new request in the protocol. 
Now, the active node for a transaction will send update request messages to the 
owners of the stale accessed objects, in order to get their updated versions. Such 
update requests are sent along with executing the transaction, in order to ensure 
that the objects accessed by the transaction are up-to-date, at least to a certain 
degree. 

Minimising the number of updates (obtained with higher thresholds) in- 
creases the number of transactions executed in the system per second, because 
that will decrease the resources used by update propagation. On the other hand, 
this minimisation causes an increase in the number of aborted transactions, be- 
cause the number of outdated objects will also be increased. The increase of the 
abortion rate can also degrade the productivity of the system, because the time 
spent for transactions that finally abort is futile. 



3.3 Experimental Validation 

The implementation of the algorithm allowed us to validate it empirically. We 
scheduled a test plan, in order to validate the simulations performed, as well as 
the predicted improvement for the abortion rates. 

Our results (figure 3(a)) compared the number of objects predicted to be 
outdated with the number of objects actually outdated. The prediction is an 
upper bound -in global terms- of the probability for an object to be stale. In 
the figure, the diagonal shows the behaviour of a perfect predictor, where the 
same number of predictions should terminate with an abortion. The points shown 
in the figure are slightly below, though close to this ideal line, evidencing the 
pessimistic behaviour of this prediction. 

When comparing figure 3(b) with figure 1 obtained by simulation, the former 
shows a more diffuse layout of the measurements with respect to the diagonal 
than the simulated results. Nevertheless, these differences are small enough to 
sustain the validity of our conclusions. 

We also measured the improvement of our real implementation. A set of 
tests were performed, specifying for each one a different threshold used in the 
algorithm. When the value of PA(oi) exceeds the established threshold, the 
object is considered to be stale, and the update is requested before such object 
is accessed. The higher the threshold is, the less requests are performed, and the 
lower the overhead. In contrast, higher values for the threshold produce higher 
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Real Environment 





(a) Accuracy of the prediction 



(b) Prediction aggregate accuracy 



Fig. 3. Accuracy of the prediction for an autoadaptive threshold 



Read-only Service time through UPDATE I 



Read-write Service time through UPDATE time 





(a) Read-only transactions 



(b) Read-write transactions 



Fig. 4. Evolution of the service time in the optimum for different Klur 



abortion rates, degrading also the performance of the system, because the use 
of computation resources of an aborted transaction finally becomes futile. 

Figure 4 shows the performance (service time) obtained in the optimum 
configuration of the algorithm, for different network costs, represented by Klur 
(when Klur = 2, the networking cost of each update request will cost twice the 
cost of a database object recovery) . 

Optimising the algorithm to minimise the abortion rate, the protocol yields 
performances comparable to the eager ones, while the optimisation of the per- 
formance yields results similar to the obtained with a lazy approach. 

Regarding the abortion rate, the results (figure 5) show that the abortion 
rates obtained by the algorithm were close to the lazy ones, when it was optimised 
for improving the performance. In contrast, the optimisation of the abortion 
rate produced results similar to those provided by eager update protocols. In 
summary, an adequate establishment of the threshold entailed low abortion rates, 
at reasonable computational costs. 
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Abortion rate through UPDATE time 




UPDATE time 



Fig. 5. Evolution of the abortion rate in the optimum for different Klur 



4 Optimising the Implementation 
Using Formal Techniques 

We encountered the establishment of the optimal threshold key for the adequate 
functionality of our algorithm. For this reason, we designed a number of modi- 
fications of the algorithm to automate the establishment of the threshold, and 
some simplifications that provide the same results requiring only part of the 
original parameters. 



4.1 Dynamic Tuning 

When the commit phase is completed (either with an abortion or with a commit), 
the algorithm compares, for each accessed object, the predictions performed with 
the termination of the transactions. The collected annotations are summarised, 
and the threshold is modified: 



Ti - |-i — Ti x 



Khist T Q(N va im K fail) 

( Khist + 1 ) 



(4) 



being 

{ Ki nc > 1 ^ N V ain K f a n 

1.00 , if N vain = N f a u 

1 ifinc i If N va in ^ N f a il 

The expression Q(N va i n , Nf a u) gives values below, equal, or above 1, in or- 
der to decrease, keep, or increase the value of T i+ \. The constant Khist depends 
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Fig. 6. Comparison for different Klur of the optimum with adaptive threshold 



on the variability of the system (mainly Klur). To provide faster adaptabil- 
ity, Khist should take lower values. The constant Ki nc (always Ki nc > 1) de- 
pends on the variability of the transactions, taking lower values for systems with 
homogeneous transactions. Vain update requests ( N va i n ) increase the threshold, 
while unpredicted abortions ( Nf a u ) cause a threshold decrease. 

The obtained results (figure 6) validated the quality of this approach, showing 
the capability of the algorithm for performing optimally, and also for reducing 
the abortion rate. 

4.2 Simplification of the Algorithm 

The applied principle to adjust the adequate threshold considered a threshold 
(always contained in [0..1]) to be compared with the expression for PA(o,;). 
Further experiments showed us that the adjustment of such threshold could be 
simplified. In other words, the expression of PA(pi) is used as a sorting function 
of each object access. Then, the threshold is established to determine, within 
this arrangement, the limits of ’’good” and ’’bad” occurrences. 

Theoretically, any other sorting function, equivalent to the original one, 
should provide the same arrangement of the accesses, and an analogous algo- 
rithm could be designed to specify the corresponding threshold within the new 
arrangement. 



The Simplified Dynamic Tuning. Observing the expression for PA(o,), and 
with some simple computations, it is easy to see that the expression follows 
a similar continuity pattern as the expression S (oi), due to the fact that TV, nwwt 
and wtps depend on the environment, and can be introduced in the algorithm 
by the threshold adjustment. 

Thus, the simplification consists in the replacement of the computation of 
PA(oi) by S(oi). In addition, the new threshold is not a value for a maximal 
probability (€E [0..1]), but it is now a maximal value for the S(oi). 
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Consequently, the algorithm only requires the use of 5(oi) : and no other 
parameter is required to be collected or transmitted. Finally, the autoadaptive 
threshold adjustment was also simplified. The results of such modification were 
identical to the ones obtained from the basic autoadaptive algorithm, with the 
benefits of a lower computational cost. 



Improving the Granularity. Another benefit derived from the simplification 
of the expression consisted of incrementing the granularity of the solution. Now, 
the value of the threshold could be applied for each particular object, rather 
than for the entire system. 

Thus, the final version of the algorithm makes use of a general threshold ad- 
justment for those objects that carry only a small amount of historical informa- 
tion (or even nothing). In addition, objects frequently accessed can be managed 
with particular information, thus producing more accurate predictions. 

However, this approach needs that the system manages a higher amount of 
metadata. In fact, for each object, the local time for each local update has to be 
stored (it is needed to calculate S(oi) in each access), plus its latest threshold, and 
the number of observations for it (used to choose between the general threshold 
and the particular one). 

At the cost of this increase on disk usage (the metadata can be also stored 
in the database), and being it possible to introduce marginal overheads in terms 
of metadata recovery (the S(oi) metadata must be collected and calculated in 
any case), the system showed to offer a better response in heterogeneous en- 
vironments, where the database objects are not accessed with the same access 
pattern. 



5 Related Work 

Current work in consistency protocols for replicated databases can be found 
using either eager [11, 12, 13, 14] and lazy protocols [15, 16, 17]. Each one has 
its pros and cons, as described in [2]. Eager protocols usually hamper the update 
performance and increase transaction response times but, on the positive side, 
they can yield serializable execution of multiple transactions without requiring 
too much effort. On the other hand, lazy protocols may allow a transaction to 
read outdated versions of objects, which may increase the abortion rate but 
usually improves transaction response times. 

Pessimistic consistency control for distributed databases [18] is based on the 
principle of “locks” , preventing concurrent transactions to access the same object 
in an inadequate mode, thus minimising the number of aborted transactions, but 
at the cost of a degrading performance, due to the suspension produced by the 
locks and the complexity of distributed locking. 

On the other hand, the traditional approach for optimistic consistency con- 
trol [19] has its main advantage in the reduction of the blocking time of the 
transactions, using “versions” (or “timestamps” [20]) as the basis for its imple- 
mentation. Its main disadvantage consists in the increase of the abortion rate. 
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Lazy update protocols [15, 16, 17] presented a new approach for update prop- 
agation, in contrast to the traditionally used “eager replication”. Lazy update 
protocols take advantage of the fact that an object can be written several times 
for different transactions before another transaction tries to read it. 

6 Conclusions 

Lazy update protocols have not been widely exploited due to their excessive 
abortion rate in scenarios with high probability of access conflicts. Nevertheless, 
such protocols can provide important improvements in the performance of a dis- 
tributed system, when the abortion rate can be kept low and the access patterns 
have a sufficient degree of locality. 

We have presented the development of a new approach for update propa- 
gation protocols, based on a statistical study of the abortion rate (the main 
disadvantage of lazy protocols) , in order to obtain an expression for the proba- 
bility for an accessed object to be out of date ( PA out d{oi )). 

An autoadaptive technique for dynamically tuning the designed algorithm 
was also analyzed. The results showed that such algorithm improves the prob- 
ability for an object to be up-to-date, thus reducing the abortion rate of lazy 
update protocols with a minimal cost in terms of performance. 

Finally, the algorithm was simplified, making use of a simple continuity anal- 
ysis for obtaining a reduced expression to be computed at a minimal cost, and 
with the most possible independence of parameters external to the processing 
node. The algorithm was finally improved in terms of the solution’s granularity, 
resulting in a good approach for managing heterogeneous replication scenarios. 
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Abstract. We apply the PEPA nets modelling language to modelling a 
peer-to-peer medical informatics application, the FieldCare PDA-based 
medical records system developed by SINTEF Telecom and Informat- 
ics, Norway. Medical data on accident victims is entered by medics on 
handheld devices at the crash site and propagated wirelessly from peer 
to peer in order to improve information flow and reduce the potential for 
data loss. The benefits of such a system include improved reliability in 
patient care and the ability for hospitals to prepare better for incoming 
trauma patients. The effectiveness and usefulness of the system in prac- 
tice depends upon both reliability and performance issues. We analyse 
the functioning of the application through a high-level model expressed 
in the PEPA nets modelling language, a coloured stochastic Petri net 
in which the tokens are terms of Hillston’s Performance Evaluation Pro- 
cess Algebra (PEPA). We use the PRISM probabilistic model checker to 
solve the model and evaluate probabilistically quantified formulae which 
quantify the responsiveness of the system. 



1 Introduction 

Public medical emergencies occur when trains are derailed or when aeroplanes 
or other multi-passenger vehicles crash. Doctors and paramedics are dispatched 
to the crash site in order to assess the severity of injuries, dispense medication 
and provide best-effort treatment for the victims in situ. Typically the majority 
of the most seriously-injured patients are transported by medical ambulance to 
a hospital for further treatment. With them is sent a transcript of the treatment 
administered at the crash site together with the assessment of the attending 
physician of the severity of the injuries. The record of medicines dispensed is 
a vital piece of documentation, preventing potentially injurious overdosing with 
another drug. Similarly the assessment of the on-site physician contains very 
important data, facilitating speedy prioritisation of the incoming patients. 

At present this documentation is most often sent as paper records or cards 
which are attached to the patient’s clothing. The intention is that when the 
patient reaches hospital they, and their records, can be transferred into the 
care of another doctor. In practice the process of documenting treatment in 
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this way does not always work well. Records and cards can be lost or damaged 
or unreadable and the only copy of important medical data is compromised. 
This usually leads to a predictably poor outcome — overdosing a patient with an 
already-administered drug, or incorrectly prioritising patients when determining 
treatment order and thereby lessening the chances of survival of a badly-injured 
patient. 

Medical informatics researchers are working to replace these systems with 
technologically superior ones. One such effort is the FieldCare project, initiated 
by SINTEF Telecom and Informatics, Norway [1]. The intention of this project 
is to equip emergency rescue medics in Norway with handheld PDAs on which 
is recorded the relevant patient information. This information is then replicated 
from PDA to PDA in peer-to-peer fashion in order to improve the robustness of 
the information storage. The functioning principle of the system is that all data 
should be replicated to every potential medical site. Patient care is often handed 
on from one doctor to another rapidly and poor information flow can be a cause 
of errors. The propagation of information through the system allows hospital 
staff to make appropriate preparations in advance of the arrival of patients at 
hospitals. 

The timely operation of a mobile computing system such as this is a sig- 
nificant concern. In this paper we present a model of the FieldCare system 
implemented as a PEPA net [2], and present an analysis of the system based 
on this model. PEPA nets are ideally suited to represent a system in which 
the components of the system find themselves working in a changing context 
due to mobility. Our analysis is based on the PRISM stochastic model checking 
tool [3] which allows us to express desirable features of the model in Continuous 
Stochastic Logic (CSL) [4], a logical specification language which incorporates 
time- and probability-bounded operators. 

The remainder of the paper is organised as follows. In the following section 
we give a description of the PEPA nets formalism, and its tool support. This 
includes an explanation of how a PEPA net model can be used as input to the 
PRISM model checker. In Section 3 we describe the FieldCare system in more 
detail and present the PEPA net representation of it. The analysis of this system, 
is given in Section 4, together with a brief overview of the CSL stochastic logic 
which we use to express desirable properties of the model. Finally, in Section 5, 
we discuss our conclusions. 



2 PEPA Nets 

In this section we provide a brief overview of PEPA nets and the PEPA stochas- 
tic process algebra. A fuller description, together with supporting theory and 
proofs is available in [2] and [5]. The purpose of this summary is to provide 
enough information about the modelling language to make the present paper 
self-contained. 

The tokens of a PEPA net are terms of the PEPA stochastic process algebra 
which define the behaviour of components via the activities they undertake and 
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the interactions between them. One example of a PEPA component would be 
a File object which can be opened for reading or writing, have data read (or 
written) and closed. Such an object would understand the methods openRead (), 
openWrite)), read(), writeQ and close(). A PEPA model shows the order in 
which such methods can be invoked. 

File = ( openRead , r 0 ) .InStream + ( openWrite , To) ■ OutStream 
InStream = (read, rr) -InStream + (close, re). File 
OutStream = (write, ryj). OutStream + (close, re) -File 

Every activity in the model incurs an execution cost which is quantified by an 
estimate of the (exponentially-distributed) rate at which it can occur (ro, rr, 
rw, r c ). 

Such a description documents a high-level protocol for using File objects, 
from which it is possible to derive properties such as “it is not possible to write 
to a closed file” and “read and write operations cannot be interleaved: the file 
must be closed and re-opened first” . 

A PEPA net is made up of PEPA contexts, one at each place in the net. 
A context consists of a number of static components (possibly zero) and a number 
of cells (at least one). Like a memory location in an imperative program, a cell 
is a storage area to be filled by a datum of a particular type. In particular in 
a PEPA net, a cell is a storage area dedicated to storing a PEPA component, 
such as the File object described above. The components which fill cells can 
circulate as the tokens of the net. In contrast, the static components cannot 
move. A typical place might be the following: 

File{-\ ^ FileReader 

where the cooperation set L in this case is A.(File ), the complete action type set of 
the component, (openRead, openWrite, . . . ). This place has a File-type cell and 
a static component, FileReader, which can process the file when it arrives. When 
components cooperate in this way it will usually be the case that one is the active 
participant (which determines the rate at which the activity is performed) and 
the other is the passive participant (who is delayed until the activity completes, 
and cannot hurry its completion). The PEPA notation to denote the passive 
participant in a cooperation is to use the distinguished symbol T in place of 
their rate variable. Thus (a, r) and (a, T) can cooperate over a to produce 
a shared activity (a, r). The case where two active participants cooperate is 
defined in [5]. 

A PEPA net differentiates between two types of change of state. We refer 
to these as firings of the net and transitions of PEPA components. Each are 
special cases of PEPA activities. Transitions of PEPA components will typically 
be used to model small-scale (or local) changes of state as components undertake 
activities. Firings of the net will typically be used to model macro-step (or global) 
changes of state such as context switches, breakdowns and repairs, one thread 
yielding to another, or a mobile software agent moving from one network host 
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N : 


:= D+M 


(net) 


M: 


'■= {M P , . . .) 


(marking) 


Mp : 


:= P [C, . . .} 


(place marking) 


D : 


:= 1= S 


(component defn) 




1 p[q = p[c\ 


(place defn) 




| P[C, ...] = P[G\ 


^ P (place defn) 



P ::= P ^ P (cooperation) 

| P/L (hiding) 

I m (cell) 

| / (identifier) 

C ::= (empty) 

| S (full) 



S ::= (a, r).S (prefix) 

| S + S (choice) 

| I (identifier) 



Fig. 1 . The syntax of PEPA nets 



to another. The set of all firings is denoted by Af. The set of all transitions is 
denoted by At- We distinguish firings syntactically by printing their names in 
boldface. 

Continuing our example, we introduce an instant message as a type of trans- 
missible file. 

InstantMessage = (transmit, rf).File 

Part of a definition of a PEPA net which models the passage of instant messages 
is shown below. An instant message IM can be moved from the input place on 
the left to the output place on the right by the transmit firing. In doing so it 
changes state to evolve to a File derivative, which can be read by the FileReader. 



InstantMessage [IM } 



transmit, r j-) 



File{- 



^ FileReader 



The syntax of PEPA nets is given in Figure 1. 

Definition 1 (PEPA net) A PEPA net Af is a tuple Af = (P ,T , I, O, t, i r, 
C, D , Mo) such that 

— V is a finite set of places and T is a finite set of net transitions; 

— I : T — > V is the input function and O : T — > V is the output function; 

— I : T — > (A/,K + U {T}) is the labelling function, which assigns a PEPA 
activity to each transition. The rate determines the negative exponential dis- 
tribution governing the delay associated with the transition; 

— 7r : Af — > N is the priority function which assigns priorities ( represented by 
natural numbers) to firing action types; 

— C : V — > P is the place definition function which assigns a PEPA context, 
containing at least one cell, to each place; 

— D is the set of token component definitions; 

— Mq is the initial marking of the net. 
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The structured operational semantics, given in [2], gives a precise definition of 
the possible evolution of a PEPA net, and shows how a Continuous-Time Markov 
Chain (CTMC) can be derived, treating each marking as a distinct state. 

The firing rule for PEPA nets is a natural extension of the classical firing rule. 
A transition may fire if there is an input token corresponding to each input arc 
which can perform a firing activity of the appropriate type. However in addition 
we require that there is a vacant cell of the correct type corresponding to each 
output arc of the transition (see [6] for details) . 

2.1 Tool Support for PEPA Nets 

We see the provision of tool support for modelling languages as being analogous 
to providing tools for programming languages. A software development kit used 
by a software engineer typically provides a range of tools (compilers, debuggers, 
profilers, perhaps even model checkers) which perform various types of anal- 
ysis or conversion on the program. Similarly a model development kit used by 
a performance engineer contains steady-state and transient solvers, passage-time 
analysers, model-checkers and other tools which implement a range of analyses 
for models in the modelling language used. 

PEPA nets are directly supported by the PEPA Workbench for PEPA nets, 
ML Edition [2]. This extends the PEPA Workbench [7] to implement the seman- 
tics of the PEPA nets language directly. 

Since there already exists comprehensive tool support for PEPA [7, 8, 3, 9] 
we have recently developed a compiler for PEPA nets which carries out a trans- 
lation from a PEPA net to a PEPA model [6] . This has the effect of removing the 
locations within the model and encoding them implicitly within state and activ- 
ity names. The benefit of this approach is that it allows us to exploit existing 
tools for PEPA, such as the PRISM probabilistic model checker [3]. 

In order to define and analyse a model, PRISM requires two input files: a de- 
scription of the system under investigation expressed in a language of reactive 
modules and a set of properties to be checked against it. To integrate PEPA, we 
built a compiler which compiles PEPA into the reactive modules language. Ad- 
ditionally, PRISM was extended to support PEPA’s combinators (parallel and 
hiding). The PRISM implementation is based on the CUDD [10] binary decision 
diagram (BDD) library which provides multi-terminal BDD data structures and 
algorithms. In PRISM, analysis of CTMCs is performed through model checking 
specifications in the probabilistic temporal logic CSL (see Section 4). 

3 The FieldCare System and Its PEPA Net Model 

3.1 Description 

As previously explained, the FieldCare system has been developed in [1] to ad- 
dress the need of medical teams dealing with accidents to share the information 
about the status of individual patients. The medical teams include the staff pro- 
viding first help at the accident scene, the coordination staff at the scene, the 
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ambulance staff and dispatchers in central control rooms, and the local hospi- 
tals’ staff preparing for the arrival of the casualties. The team members record 
the information about the patients using hand-held and other computers linked 
together in a wireless network. The network and team will be very dynamic with 
members joining and leaving at very short notice. 

The particular concern of the authors was to investigate how to achieve 
reliable data replication between the nodes in a network where some users are 
very mobile, the radio links may suffer intermittent failures and the connection 
topology between nodes may vary as team members move around, including 
moving out of range of a base station. To quote [1], “The goal is that all data, 
about all patients, should be stored on all nodes.”. All nodes have the same 
status: there is no central server. Fortunately, the lifetime of the database is 
rather short and the volume of data entered by each user will not be great. 
Because PDAs are diskless, supporting record-based storage, the entire database 
will have to be stored in main memory in each PDA. The PDAs are not multi- 
function; they are specialised only to supporting the FieldCare application. There 
is one such PDA for each team. 



The Reliable Data Replication Approach: Basic Idea. The approach 
developed consists of replicating everything to everyone. The objective is that 
all data about all patients should be stored on all nodes. Thus, data entered on 
one node must be replicated to all nodes including those that are added to the 
network afterwards. To achieve that each node has a copy of the database and 
maintains its own transaction table. 

The database is assumed to have a very simple data model where each record 
consists of patient identification number, time stamp, name of the team, and 
details of the medical observation. All transactions in the database have an 
identifier which is unique throughout the network. The identifier is generated on 
the node at which the transaction is originated. Only INSERT operations are 
allowed on the database; DELETE and MODIFY are not allowed. Furthermore, 
full database transaction consistency is not necessary; temporary inconsistency 
between the local copies of the database during data replication is acceptable [1], 

The transaction table is unique to the node. It contains one row for each 
transaction entered in the local copy of the database and shows, for each current 
neighbour of the node, which transactions it is known to have. To achieve this a 
column is created and initialised to false for each new neighbouring node. Two 
additional columns are used, one for the unique transaction identifier and one for 
the transaction sequence number. The identifier is assigned to the transaction by 
the node where it is originated and the sequence number is local to each node. 
This corresponds to the position in which the transaction has been entered in 
the table. Table 1 shows an example. 



Transactions Available Protocol. When a new transaction is generated in a 
node, an identifier is assigned and it is inserted in the local database. A new row 
is added to the transaction table and the columns corresponding to all current 
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Transaction name 


Sequence no. 


Neighbour 1 




Neighbour n 


(n, 1) 


1 


true 




false 


(n, 2) 


2 


true 




true 


O, i) 


3 


false 




true 



Table 1. Transaction table 



neighbouring nodes are initialised to false for this new row. The node sends a 
Transaction offer message to each of its neighbours, to which it expects to receive 
a Please send answer. The node then sends the new transaction using a Data 
update command. When the neighbouring node receives the new patient record, 
it sends an I've got it message. In the original node this triggers a change in the 
corresponding column value to true. 

Frequent communication failures are anticipated and because of this expec- 
tation there are sporadic updates between neighbouring nodes. Thus each node 
checks periodically if its current neighbours have all the transactions reported in 
its own transaction table. The node sends a Transaction offer message to those 
neighbours whose corresponding column for the transaction offered is still set to 
false. The contacted node may respond either with an I’ve got it message because 
it already has the transaction in its local database or a Please send message. In 
the latter case it receives a Data update command to which it answers with an 
I’ve got it message. Both nodes have then to set the column of the neighbour to 
true. 

Moreover, when a node establishes a new node communication after changing 
its position in the network, both nodes send each other a “Pleased to meet you” 
message and add a new column for each other in their respective transaction 
table. These nodes have then to offer each other all the transactions in their 
table using the exchanges of messages described above. 

The periodic check allows the network to provide a solution to the problem 
of possible losses, like the loss of an aknowledgement message I’ve got it. 

3.2 The PEPA Net Model 

Consider two geographical areas, AREA 1 and AREA 2. The former being, for 
example, the area where an accident took a place and the latter the location of 
the hospital. Moreover, consider three medical teams A, B and C moving from 
one area to the other. The PEPA net model corresponding to this situation is 
described in Figure 2. 

The PEPA net model consists of three places, namely AREAA., AREAJ2 
and OUT. Place OUT is used to model the area where a team is out of range 
of the base station of either AREA 1 or AREA 2. To model the behaviour of 
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(move_2, c) 




Fig. 2. The PEPA net Model 



the different teams, we use components TeamX where X stands for A, B or 
C. Moreover a static component Neighbour is associated with each place of the 
PEPA net network. This component allows us to keep track of the local copies 
of the database which have already been updated and the ones which still have 
to be updated. 

Component TeamX. This component models the behaviour of a node X 
representing a medical team in the wireless network. Initially a node may gen- 
erate a transaction, receive a transaction offer or a “Pleased to meet you” mes- 
sage from another node Y. These are modelled using activities generateJrans, 
trans-off er Y x and pleasedyx respectively. The two latter activities have an un- 
specified rate (T) as they are initiated by another node (component). Further- 
more a node may move from one area to another, behaviour that is captured by 
the firing activity moved where i is the area number where it moves to. 

Once a new transaction is generated and inserted ( insert-trans ) into the local 
transaction table of the node, it is offered, with activity trans-offer , and then sent 
(with activity pleasesend) to all immediate neighbours of the node, that is all 
the nodes in the same area (place) . Activity end-neighbours AX allows us to know 
when all neighbours of node X have been updated with the new transaction. 
This activity has an unspecified rate as it is controlled by component Neighbour 
presented later. 

The periodic check for changes which is done by a node is modelled us- 
ing the activity periodic-check. During this phase of the protocol, the node 
checks its transaction table using the check-table activity and offers a trans- 
action ( trans-offer ) to all its neighbours whose corresponding column has false 
as value. 
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When a node X moves to a new area it has to establish communication with 
all nodes already in the area. This is modelled by the activity pleased XY . As for 
the periodic check, the node has then to check its transaction table and to offer 
the transactions with a false value in its line to the corresponding immediate 
neighbours. Note that in this case the node has to offer all the transactions in 
its table to all its new immediate neighbours. Indeed when a node moves from 
one area to a new one, its transaction table does not keep track of its previous 
neighbours. 

When a node is within an area, it may become out of range of the base 
station of the area. This is captured in the model by the firing activity out J 
where i(= 1,2) is the node’s current area. 

TeamX = ( generate-trans , r). TeamX i + X) Y ^x(^ ease< ^YX; T). TeamXo 

+ ( periodic-check , ti). TeamXo + J 2 Y^x(^ rans -°ff er YX^ T). TeamXo 
+ (rnove. 1 , c).TearnX.M + (move_ 2 , c ).TearriX.M 

TeamX.M — X)Y^x(P^ ease ^XYi w )- TearriXM + ( end-neighbours-X,T)- TeamXo 
+ (out_l, s).TeamX M outi + (out_2, s).TeamX M out2 
TeamX o = ( check-table , C2). TeamX2 + 5 ^Y^x(^ rans -°J 0 rer YX> T). TeamXsa 
+ (out_l, s) . TeamXoouti + (out_2, s) . TeamX 0o „ t 2 

TeamX 1 = ( insert-trans, r 1 ) . TeamX 2 

TeamX 2 = '} 2 Y ^. x (trans-offer XY , r2) ■ TeamXs + ( endjrieighboursYX , T). TeamX 
+ (out_l, s) . TeamX 2 „uti + (out_2, s) . TeamX 2 o„ t 2 
TeamX 3 = ^ 2 Y , x (pleasesend YX , T). TearuXi + X) Y ^x^’ ve - 9 0 ^-^YX’ T). TeamXs 
+ (out_l, s) . TeamXoouti + (out_2, s).TeamX 3out 2 

TeamX 4 = '} 2 Y ^ i y^{databasejupdate^ Y ,r 3 ).TeamX 3 + (out_l, s).TeamX4„ ut i 
+ (out_2, s).TeamX 4 o„ t 2 
TeamX 5 = (set-true-receiver, r 4). TeamXs 

TeamXo = 5 ^ Y ^x(P^ ease -' sen ^XY> r &)- TeamX-j + ^ Y ^x(^ ,,;e -ff 0 ^-*tx Y > r s)- TeamX 
+ (out_l, s).TeamX 6out i + (out_2, s).TeamXe 0 ut2 
TeamX-j = '} 2 Y ^ x (database-update Y x_, T). TeamXs + (out_l, s). TeamX-j out \ 

+ (out_2, s). TeamXs out2 
TeamXs = [setJ,ruesender,r-j) .TeamX 

TeamXea = J 2 Y^x(P^ ease - sen ^XY^ r ®)- TeamX-; a +Yh Y ^x^ ve - 9 0 ^-^XY-> r s)- TeamXsa 
+ (out_l, s).TeamX a 6 outi + (out_2, s) .TeamX a&out 2 
TeamXT a = J 2 y ^ x(^ a ^ a ^ ase - u P^ a ^ e YX*~^)- r ^ eam X 8 a + (out_l, s).TeamX a r out i 
+ (out_2, s).TeamX a 7 o ut2 
TeamXsa — (set-truesender, r?) .TeamXo 
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In component TeamX the derivatives TeamX kour i are defined as follows 
TeamX kouti = (inJ, r ).TeamX k 

indicating that for a node which has moved out of range, when it returns it 
does so in the same state. Firing activity in_i models the case where the node 
becomes reachable again. That is, it is no longer out of range. 



Component Neighbour. Component Neighbour allows us to keep track of 
the nodes which have received a transaction offer and the ones which have not. 
Similarly it allows us to identify the current node(s) of an area with which a 
newly arriving node has established communication. The complete behaviour of 
the component when there are three nodes or teams A, B and C, in the network 
is as follows: 



Neighbour 


def 




+ 




+ 




+ 




+ 




+ 




+ 


Next AB 


def 




+ 


Next A c 


def 




+ 


Next BA 


def 




+ 


Nextsc 


def 




+ 



(trans.offer AB , T).NextAc + ( trans-offer AC , T ).Next A s 
(trans.off er BA , T).NextsA + (trans.offer BG , T ).Nextsc 
( trans.offer CA , T ) . NextcB + ( trans .offer GB , T ) . Next GA 
(pleased AB , T).Next A c + (pleased AC , T ).Next A s 
(pleased BA , T).Nextsc + ( pleased BG , T ).Nextsc 
(pleased GAl T). NextcB + (pleased CB ,T).Nextc A 

H2x-a b G (end.neighbours^K , p). Neighbour 

(trans.offer AB , T ).Next+ (pleased AB ^ T). Neighbour 

(end.neighbours-A, p). Neighbour 

(trans.off 'er AC , T).Next + ( pleased AC , T ). Neighbour 

(end.neighbours-A, p). Neighbour 

(trans-off er BA , T).Next+ (pleased B ^T). Neighbour 

(end.neighbours-B , p). Neighbour 

(trans-offer BG , T).Next + (pleased BC , T ) .Neighbour 

(end.neighbours-B , p). Neighbour 



Nextc A = (trans.offer GA ,T).Next+ (pleased CA: T). Neighbour 
+ (end.neighbours.C, p). Neighbour 
NextcB — (trans.offer CB ,T).Next+ (pleased CB ,T). Neighbour 
+ (end.neighbours.C, p). Neighbour 
Next =Y,x=a,b,c (end.neighbours-X , p). Neighbour 

The Neighbour component does not have a physical counterpart in the system 
but can be regarded as representing the knowledge embodied in the wireless 
LAN, for purposes such as broadcast messaging. 



The Initial Marking. The initial marking of the system we consider is the 
one corresponding to Figure 2. 
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^ Neighbour IXI (( TeamA[TeamA] XI TeamB[TeamB ]) ^ TeamC[J \ ), 
Neighbour IXI (( TeamA{_ ] IXI TeamB[Jf) ^ TeamC{TeamC]), 
TeamA[f\ CXI TeamB[f\ CXI TeamC[-\^j 

The cooperation sets /C, K! and C are defined as follows: 

K. = { trans-offer AB , trans-offer BA , pleasesend AB , database-update A b , 
I’ve-got_it AB } 

1C 1 = {trans-offer AC , trans-offer BC , trans-offer CB , trans-offer CA , pleasesend AG , 
I’ve-got-it A Q, database-update A q , database-update B q , please_send B Q , 
I’ve-got_it B Q} 

£ = {trans-offer AB ,trans_offer AC , trcms-offer BA , trans.offer BC , trans_offer CA , 
trans-offer q B , end_neighbours_A, endjneighboursJ3 , end_neighboursJL 7 , 
pleased AB , pleased A q, pleased BA ,pleased BG , pleased q A , pleased CB } 



4 Model Analysis 

The PRISM model checker supports the analysis of probabilistic and stochas- 
tic systems by allowing a modeller to check a logical property against a model. 
Several logics and several types of model are supported. Recently the CSL logic 
(Continuous Stochastic Logic) [4] has gained some acceptance as a suitable vehi- 
cle for expressing performance and performability measures which can be model 
checked on a CTMC. A CSL formula expresses an assertion about the perfor- 
mance measures of a model which can then be checked to see whether it is true 
or not. The syntax of CSL is: 

(j) ::= true \ false \ a \ (f A \ (f V 4> \ ->4> \ T’mpIV’] I 
::= X tj> | 0 U 7 cf | (p U (f 

where a is an atomic proposition, xi £ {<,<,>,>} is a relational parameter, 
p £ [0, 1] is a probability, and I is an interval of R. An action-based version of 
CSL has been defined [1 ] but is not supported by PRISM. 

Paths of interest through the states of the model are characterised by the 
path formulae specified by V . Path formulae either refer to the next state (using 
the X operator) , or record that one proposition is always satisfied until another 
is achieved (the until-formulae use the U-operator). Performance information is 
encoded into the CSL formulae via the time-bounded until operator (U 7 ) and 
the steady-state operator, S. 

It is sometimes convenient to introduce some derived operators in order to 
help with the expression of a CSL formula. These operators do not add to the 
expressive power of the logic, they simply help to make the statements of some 
formulae more compact. One such operator is implication (=>•) which can be 
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Fig. 3. Plot of satisfying states for the FieldCare model with p = 0.9 




defined in the usual way, (f>\ =>• <f >2 = ~^4>i V (f> 2 . Another useful operator is time- 
bounded, eventually (O 7 , where I is an interval of time) which is defined thus: 
0 1 (f) = true U 7 (j>. This operator is frequently used with intervals of the form [0, t\ 
to capture formally the concept of 11 within t time units" . 

These derived operators are used in our present case study in the following 
way. We wish to capture the situation where information sent by one of the 
participants in the protocol is received by another within a suitable time frame. 
In a framework with only one sender and one receiver we can characterise the 
sending and receiving events by two atomic propositions, s and r. Then the 
property which we are interested in can be expressed in CSL as follows. 

<2>=s =^V> p [0^ t] r] 

This is a typical CSL formula, combining time, probability and a path through 
the system evolution. The above formula characterises all states for which either 
a send event does not occur or it does occur and then a receive event occurs 
within time t with probability at least p. 

Hence, the CSL model-checking problem which we want to check is that 
Sat(^) = S, where S is the complete state-space of the model. 



4.1 Probabilistic Model Checking 

In model-checking our CSL formula against our model of the FieldCare system 
we investigated the formula when p held the value 0.9. We found that the 
critical time-frame where returns significant information is for t between 40 
and 54 seconds. For values of t less than 40 the formula is true in just those 
states where a send event does not occur (178432 of the 182002 states of the 
model are in this subspace). For values of t greater than 54 the formula is true 
even if a send event occurs because with probability at least 0.9 the information 
will be received within 54 seconds (all of the 182002 states of the model are in 
this subspace). Figure 3 presents these results. 
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Fig. 4. Plot showing the probability of successfully updating the database decreasing 
as the rate of movement of teams increases 



By presenting the number of satisfying states instead of simply a single truth 
value PRISM guides the modeller through experimentation with the model in 
order to select subsequent formulae to verify. If the present formula is true in 
nearly all of the states in the model then the next values for the probabilistic 
or time bounds might be close to the present ones. If the formula is satisfied in 
only a small number of states the next values chosen might be further away. 

In studying the growth of the satisfying states in the model we see that 
the curve is not totally smooth. At around 50 seconds there is a small kink in 
the curve as a slightly larger than usual subset of the state space moves into 
the satisfying set for the formula. Shortly after the growth of this set slows. 
Variations such as this are readily explained as being caused by variability in 
the connectivity of components in the model. 

4.2 Performance Analysis 

In addition to model-checking the above formulae we undertook a classical per- 
formance analysis of the model. We used the sparse matrix engine of the PRISM 
tool with its implementation of the Jacobi over-relaxation numerical routine to 
solve the CTMC representation of the model for its stationary probability dis- 
tribution. This is an efficient procedure, taking (approximately) 400 seconds to 
compute on a Pentium IV processor running at 1.8GHz with 256MB of physical 
RAM. 

We then focussed on the probability of being in a distinguished subset of the 
state space, determined formally from our high-level PEPA net model. Figure 4 
shows the impact of the increase in rate of movement of team TeamB from one 
area to another on the database update probability of Team A. As the speed of 
movement increases, the probability Pba of updating the database of TeamA 
decreases. This is the most typical case where one of the teams is more often 
required to move than the other one. 
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5 Conclusions 

In this paper we have applied the PEPA nets modelling language to the analysis 
of a model of a real-world application, the FieldCare medical emergency system 
being developed by SINTEF Telecom and Informatics, Norway. This application 
will be used in a safety-critical setting and therefore deserves considered analysis 
and investigation before it is deployed in earnest. 

The analysis which we applied to the system is undertaken by making a high- 
level model, abstracting away much unnecessary detail in order to focus more 
clearly on the salient aspects of the problem. Building performance models of re- 
alistic real-world systems is an activity which requires careful attention to detail 
in order to model correctly the intended behaviour of the system. Proceeding 
with care during this part of the modelling process is a wise investment of effort. 
If the initial performance model contains errors then all of the computational 
expense incurred in solving the model and all of the intellectual effort invested in 
the analysis and interpretation of the results obtained would at best be wasted. 
In general interpreting a model with errors could lead to making flawed decisions 
based on erroneous conclusions made from erroneous results. This can lead to 
perhaps classifying systems as being effectively reliable when a high-level model 
without these flaws would have demonstrated that they are not. For this reason 
we consider it important to work with structured, high-level modelling languages 
which directly support the concepts and idioms of the application domain, such 
as mobility of users and devices. 

Using a suitable high-level modelling language, the PEPA nets notation, 
our analysis focussed on correctly capturing the behaviour of this dynamically- 
varying system in use and probing the timely behaviour of its key function: 
propagating critical data to all neighbours in a peer-to-peer application using 
a simple and robust protocol. Using the PRISM probabilistic model checker 
as our analysis tool we were able to ascertain how delays on the receiving of 
propagated medical information would impact on the system in use. 

Other analysis tools for PEPA provide complementary analysis capabilities 
to those which are provided by PRISM. The Imperial PEPA Compiler (IPC) [9] 
uses the DNAmaca tool [12] to compute passage-time quantiles for passages 
through the model delimited by a set of starting states and a set of terminating 
states. This could be used to investigate other measures over the behaviour of 
the system including quantifying averages and extremes in response times. One 
of the reasons to model with a well-supported formal language such as PEPA is 
that a range of analysis options are available. 

Many concerns and questions remain about peer-to-peer emergency medial 
systems such as FieldCare. Our analysis has said nothing about other very im- 
portant aspects of the application such as resistance to malicious attack by 
hostile users of other mobile devices in the area. Similarly other analyses would 
be appropriate. The application is to be implemented using Java technology 
operating on hand-held devices under far from ideal conditions of use. We have 
thrown no light on whether or not the implementation technology can withstand 
this challenge. Aspects such as these remain to be considered carefully by the 
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designers and developers of the system before the system is deployed in earnest 
in a life-critical situation. 
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Abstract. Software design methodologies are incorporating non func- 
tional features on design system descriptions. MASCOT which has been 
a traditional design methodology for European defence companies has 
no performance extension. In this paper we present a set of performance 
annotations to the MASCOT methodology, called MASCOTime. These 
annotations are extending the MDL (MASCOT Description Language) 
design components transparently. Thus, in order to evaluate the perfor- 
mance of the annotated software designs, a discrete-event simulator pro- 
totype is also introduced. The prototype has been implemented with Java 
objects which are isomorphic to the MASCOTime components. Several 
examples of MASCOTime models and simulation results are also shown. 



1 Introduction 

Soft real-time systems differ from traditional software systems in that they have 
a dual notion of logical correctness. Logical correctness of a real-time system is 
based on both the correctness of the output and timeliness. That is, in addition to 
producing the correct output, soft real-time systems must produce it in a timely 
manner [2], [4], 

One of the most usual approaches to software engineering is based on the 
concept of a system as a set of interacting components. In order to characterize 
the interaction between the components is also necessary to express a protocol 
representing the timing constraints on the interaction and to its support by an 
explicit interconnection in the future implemented system [2]. On the other hand, 
a software design defines how a software system is structured into components 
and also defines the interfaces among them. 

MASCOT (Modular Approach to Software Construction Operation and Test) 
is a design and implementation method for real-time software development and 
brings together a co-ordinated set of techniques for dealing with the design, con- 
struction (system building), operation (run-time execution) and testing software, 
as its acronym wants to depict [21]. 

At the heart of MASCOT there is a particular form of software structure sup- 
ported by complementary diagrammatic and textual notations. These notations 
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give visibility to the design as it emerges during development, and implementa- 
tion takes place via special construction tools that operate directly on the design 
data. MADGE (Mascot Design Generator) is one of these tools [7]. Design visi- 
bility greatly eases the task of development management, and the constructional 
approach ensures conformity of implementation to design, and allows traceability 
of performance back to design. 

The functional model allows a system to be described in terms of indepen- 
dently functional units interacting through defined transfers of information. Here 
is introduced the notion of protocol component which is used to annotate the 
interaction between processes with a MASCOT representation [22]. 

Unfortunately, MASCOT does not provide any kind of performance con- 
straint annotation on its functional components that could estimate, running 
a performance evaluation tool, whether the system being designed will meet or 
not the performance requirements. 

In this paper, we present MASCOTime as the main contribution to the inte- 
gration of performance engineering practices into a traditional system engineer- 
ing methodology through performance constraint annotations. MASCOTime in- 
terferes minimally with the functional description on original MDL (MASCOT 
Description Language). In this way, system/software engineers do not perceive 
any change in the functional description of the future system. 

However, once the system design method has been augmented with perfor- 
mance annotations, the information provided for the explicit system design is 
not evaluated itself. It is necessary either to build a performance tool to directly 
compute or estimate the performance of the model that MASCOTime gener- 
ates or to transform the augmented model to other formalism before its indirect 
evaluation. Since a model could be as complex as the system designer wants, 
flexibility on evaluation must be achievable. Therefore, we also present a proto- 
type of discrete-event simulator for MASCOTime designs. The implementation 
of the simulator has been developed using objects that represent directly the 
MASCOTime (and also original MASCOT) components. Thus, the simulated 
components that build a system and the objects that the simulator manages 
are isomorphic. Due to the restrictions that would be imposed to the functional 
(and performance) model to apply analytical or numerical algorithms, we decide 
to avoid transforming the MASCOTime model to a traditional formal model for 
performance evaluation [8] . The discrete-event simulator uses a direct translation 
between the MASCOTime components and their isomorphic Java objects. 

In the following section, direct related works are reminded. In section 3 we 
are going to review the MASCOT design methodology. Section 4 is focused 
in the MASCOT Description Language (MDL) as textual description of MAS- 
COT designs. In section 5, we propose MASCOTime as performance engineering 
extension of MDL blocks. Therefore, in section 6 a discrete-event simulator pro- 
totype for MASCOTime designs is overviewed and finally the conclusions and 
future work are given in Section 7. 
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2 Related Work 

A set of well-known notations exists for each of the description of system, e.g. 
UML, without augmented information for the performance constraints. Despite 
the fact that early drafts of UML 2.0 try to fill this gap and also the huge amount 
of interesting recent software performance engineering proposals for current ver- 
sion of UML, for example in [5], [15], [20], major European defence companies, 
e.g. MBDA [ .7], do not use of UML as main system design methodology. Its 
utilization is only restricted to B2B applications or B2C applications. Thus, 
the soft real-time systems that MBDA produces are modeled with a software 
design method called MASCOT [3]. Several works have transformed the MAS- 
COT components into queueing networks to solve analytically their performance 
behavior [10], [11], [12] but no tool has been developed from this research. On 
the other hand, a new software performance engineering technique for MAS- 
COT was proposed in [19] although but it was relying on a three-stepped meta- 
model transformation whose result was not very useful. In [18] an early design 
of a queueing network solver /simulator for MASCOT diagrams was depicted. 
However, its implementation was revealed unpractical due to the inapplicability 
of analytical or approximated algorithms and also because of the indirect reso- 
lution of the models. Since the system modeling has to be flexible, we decided 
to build a discrete-event simulator. 



3 MASCOT 

The origins of MASCOT (Modular Approach to Software Construction Oper- 
ation and Test) go back to the early seventies, and in particular, to the work 
carried out at that time by Hugo Simpson and Ken Jackson at the Royal Radar 
Establishment (RRE) belonging to the U.K. Ministry of Defence. The spur for 
the creation of MASCOT came from the problems they had experienced in 
the software development for a large multi-computer real-time system. In other 
words, a large amount of code to be written for many computers operating in 
parallel and interacting in real time and with a large number of people engaged 
simultaneously on the development task that usually produced technical and 
management problems. 

The MASCOT approach to software development, as stated in [9], contains 
the following features: 

— It defines a formal method of expressing the software structure of a real-time 
system, which is independent of both computer configuration, and program- 
ming language. 

— It imposes a disciplined approach to design, which yields a highly modular 
structure, ensuring a close correspondence between design functional ele- 
ments and constructional elements for system integration. 

— It supports a program-acceptance strategy based on the verification of single 
modules, as larger collections of functionally related modules. 
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— It provides a small easily implemented executive for the dynamic control of 
program execution at run time. 

— It can be applied to all software lifecycle stages from design onwards. 

— It can form the basis for a standard system of software procurement and 
management. 

At the heart of the method there is a particular form of software structure sup- 
ported by complementary diagrammatic and textual notations. These notations 
give visibility to the architecture design as it emerges during development, and 
implementation takes place via special construction tools that operate directly on 
the design data. Design visibility greatly eases the task of development manage- 
ment, and the constructional approach ensures conformity of implementation to 
design, and allows traceability of real-time performance back to design. MADGE 
is one of these construction tools that produces MASCOT designs and auto- 
matically generates Ada code. Thus, MADGE and other tools may be used to 
consider different software/hardware architectures on design but unfortunately 
they cannot be evaluated. 

The future of no method can be predicted with certainty. Nevertheless, one 
interesting feature to be added would be the performance evaluation of the 
design elements in early stages of the system design by incorporating the time 
requirements and constraints. This article is concerned with an extension to the 
MASCOT method that makes performance evaluation of the designs easier. 

3.1 MASCOT Components 

The building blocks of MASCOT are namely, activities, intercommunication 
data areas (ID As) and servers. There are also complex components, made from 
modules of the simple ones, known as subsystems. Networks of activities, ID As, 
servers and subsystems build system designs in MASCOT methodology. 



Activities. Activities are the basic process elements in the system design. They 
are the unique active components on the MASCOT method. Every activity may 
be viewed as an implementation thread. Different activities could be executed 
in parallel but the individual tasks that they perform are sequential. Activities 
describe the overall process of the system that is being designed. Activities are 
connected asynchronously through ID As. 



Intercommunication Data Areas (IDAs). The ID As are components to 
interchange data among system tasks. Instead of communicating directly each 
other, tasks use buffer memories asynchronously. IDAs could be structured in 
any way but there are two specialized components: channels and pools. 

Channels provide unidirectional transmission of message data among activ- 
ities through a buffer. Reading is a destructive operation but writing is not 
destructive. The operations are served in FIFO manner and the capacity of the 
channel is the most important performance feature of this component. 
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Pools are data containers. Reading is not destructive (although it could be 
concurrent) but writing is a destructive operation on pools. 

Generic ID As are those which do not belong to the channel and pool families. 
They could include other ID As and activities to perform their communication. 

Routes are the newer elements in the MASCOT methodology. They are spe- 
cial cases of channels and pools. A taxonomy of these elements is provided in [13]. 
Typical components falling into this category are signals, constants, rendez-vous, 
etc. 

Servers. Servers are connecting the I/O of the system with the external en- 
vironment. They are receiving or sending data to be processed in the system 
belonging to the outside. 

Ports, Windows and Paths. Every component in MASCOT must be inter- 
connected composing a functional network via paths. A port is a set of operations 
requested by a component. A window is a set of operations offered by a compo- 
nent. Paths give equivalence among operations among windows and ports. 

4 MDL 

MASCOT provides a textual notation for components and interconnections 
known as MDL (MASCOT Description Language). An example of a MDL file 
is shown in next lines. 

SYSTEM TMS ; 

USES TMS_RADAR, TMS_INTERFACE , TMS_CORE_SUBSYSTEM, TMS_CL0CK; 

SERVER INTERFACE : TMS_INTERFACE; 

SERVER RADAR : TMS_RADAR; 

SUBSYSTEM S_CL0CK : TMS_CL0CK; 

SUBSYSTEM CORE : TMS_CORE_SUBSYSTEM ( PI = RADAR.W1 , 

P4 = INTERFACE.W2, 

P3 = INTERFACE. Wl, 

P2 = S_CL0CK.W1 ); 

END. 

Every MASCOT model is either a system or a subsystem. Therefore, the 
MDL system description is a tree structure. This code describes the TMS sys- 
tem that comprises four subsystems: the radar, the interface, the core and the 
clock. These subsystems are stored in different files by MADGE. The visibility 
of the TMS system is performed by the set of its components. For example, the 
core subsystem has four ports (PI, P2, P3 and P4) that are connected to sev- 
eral windows of the other three subsystems. Figure 1 shows the corresponding 
MASCOT diagrammatic description of the TMS system. 

On the other hand, each subsystem could be composed by other subsystems, 
channels, pools, routes, servers and activities. The following code describes the 
clock subsystem which uses a signal and performs an interruption through an 
activity. 
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Fig. 1. The MASCOT diagrammatic description of the TMS system 




Fig. 2. MASCOT diagrams corresponding to the clock subsystem 



SUBSYSTEM TMS_CL0CK; 

PROVIDES W1 : GET; 

USES CLOCK_INTERRUPT , SIGNAL; 

ACTIVITY A_CL0CK_ INTERRUPT : CLOCK. INTERRUPT 

( PI = CL0CK.INF0RMATI0N.W1 ); 

ROUTE CLOCK. INFORMATION : SIGNAL; 

W1 = CL0CK.INF0RMATI0N.W2; 

END. 

Figure 2 shows the corresponding MASCOT diagrams of the clock subsystem. 
Those kind of modular components are capable to describe the whole system with 
textual or diagrammatic descriptions. 



5 MASCOTime 

MASCOTime is a prototype of discrete-event simulator for MASCOT designs 
that shows the difference on performance among architecture candidates in early 
stages of software/system construction. 

In no way can MASCOTime be regarded as a handle-cranking technique, 
guaranteed to produce, painlessly, the solutions of complex problems. Success 
is achieved by using a modular decomposition of MASCOT approach which is 
relevant to management, design, construction and execution, and which allows 
problems that contain complexity, to be partitioned into smaller pieces. Design 
is essentially a creative process requiring the application of skill and experience. 
MADGE provides the process with visibility and code generation, which gives 
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control over it, and MASCOTime provides the performance evaluation of such 
designs. 

The software/system architecture modeled with MASCOT is based on data 
flow concepts. The simplicity of its design methodology has several advantages, 
e.g. allowing the distribution of system functionality to be represented. This tex- 
tual/diagrammatic representation provides the means for controlling functional 
interactions and their propagation among the components. However, there is 
no control in one important non-functional feature of the system that is being 
modeled: the performance of the software components or even the performance 
of the overall system. MASCOTime is an extension to MASCOT that provides 
enough performance information to evaluate the performance of the MASCOT 
related models. MASCOTime design style mainly describes the service time and 
the capabilities of the functional components and analyzes them. Therefore, 
performance annotations for the components have been added to MASCOT in 
a friendly manner, which allows derivation of a simulation model of the system’s 
architecture. 

In order to minimize the training on MASCOTime issues, the extension has 
been developed avoiding an intermediate interfacing between the design with 
performance annotations and the simulator. Thus, MASCOTime components 
and simulator objects are isomorphic. Moreover, the actions applicable on the 
components are similar to the actions to perform over the Java objects. 

5.1 MDL and MASCOTime 

Since MDL provides the textual notation of the MASCOT method, MASCO- 
Time extends the notation to incorporate performance information. The way 
that the extensions are annotated minimizes the perturbation of the functional 
model created with MDL. Thus, MASCOTime code is enclosed between {* 
and *} to be distinguished from the traditional MDL comments (written between 
{ and }). Therefore, the MDL model remains intact even though MASCOTime 
extends the file source. The following code corresponds to the extended version 
of the clock subsystem example including MASCOTime annotations. Notice that 
the MDL code is identical to the previous one, but some information has been 
added as MDL comments (between { and }). 

SUBSYSTEM TMS_CL0CK; 

PROVIDES W1 : GET; 

USES CLOCK_INTERRUPT , SIGNAL; 

ACTIVITY A_CLOCK_INTERRUPT : CL0CK_INTERRUPT(P1=CL0CK_INF0RMATI0N.W1) ; 
ROUTE CLOCK. INFORMATION : SIGNAL; 

W1 = CLOCK.INFORMATION . W2 ; 

{* 

BEGIN MASCOTIME 
[ MASCOTime Code. . .] 

END MASCOTIME 

*} 

END. 
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The first sentence of a MASCOTime block is always a BEGIN MASCOTime 
and the last END MASCOTime to enhance the visibility of the code. 



MASCOTime Components. Due to the limited extension of the paper we 
are only going to show some representative examples of the components that 
MASCOTime uses: 



CHANNEL 



► Channel: The essential per- 
formance constraints of a chan- 
nel must be its capacity and the 
mean time (and distribution) to 
read or write into the buffer. An 
example of code may be the one 
beside this paragraph. 

The channel Inf ormation_Radar is defined in a block containing its capacity 
of 4 elements, the mean time to read a position (2.5 units of time, exponentially 
distributed) and the mean time to write a position in the channel (3.0 units of 
time, exponentially distributed). 



BEGIN MASCOTIME 

DEFINE INFORMATION_RADAR 
CAPACITY (4) ; 

TREAD (EXP (2. 5) ) ; 
TWRITE(EXP(3 . 0) ) ; 

END DEFINE 
END MASCOTIME 



► Pools: As in channels, the 
mean times to read or write 
a pool are necessary to consider 
the performance of the compo- 
nent however the limit of simul- 
taneous writers may also be of 
interest. In next lines an exam- 
ple of MASCOTime pool is pro- 



BEGIN 

MASCOTIME 

DEFINE POSITION. ANTENNA : POOL 
TWRITE (HEXP (2 . 0 , 0 . 3) ) ; 

TREAD (HEXP ( 1 . 0 , 0 . 5 ) ) ; 
SYMWRITERS (3) ; 

END DEFINE 
END MASCOTIME 



vided. 

The pool position_antenna may hold up to three simultaneous writers with 
their respective mean time to read equal to 1.0 units of time (hypoexponentially 
distributed, quadratic coefficient of variation equals to 0.5). When an exclusive 
writer access the pool needs 2.0 units of time to write (also hypoexponentially 
distributed, quadratic coefficient of variation of 0.3). 



► Other Routes: The example 
corresponds to a signal element, 
a buffer with destructive writ- 
ing. The capacity of the buffer 
is two positions, and the mean 
time to read and the mean time 
to write are different amounts 
with different statistical distri- 
butions. 



BEGIN MASCOTIME 

DEFINE CLOCK.TICKS : SIGNAL 
CAPACITY(2) ; 

TREAD (HEXP ( 1 . 0 , 0 . 5 ) ) ; 
TWRITE (NORM (3. 0, 1. 0) ) ; 
END DEFINE 
END MASCOTIME 



The signal clock.ticks is defined in a block containing its capacity of 2 
elements, the mean time to read a position (1 unit of time, hypoexponentially 
distributed) and the mean time to write a position in the buffer is 3.0 units of 
time, in normal distribution with 1.0 of variation. 
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► Activity: Since the activities 
are the processing core of the 
systems, the sequences of their 
attached actions imply process- 
ing delays that is necessary to 
compute. However, the order of 
the actions in these sequences is 
not functionally trivial. 

This example shows that pool3 
is read after pooll and before 
a processing time of 10.0 units 
of time (constant) . Similarly oc- 
curs for channels, but the opera- 
tions have different parameters. 



BEGIN MASCOTIME 

DEFINE activitat.l : ACTIVITY 
BEGIN SEQUENCE 
CR0N0 ON; 

READ (pooll) ; 

READ(pool3) ; 

WAIT (CST (10.0)) ; 

WRITE ( channel 1 ) ; 
READ(channel2) ; 

WAIT (EXP (20.0)) ; 

WRITE (pool2) ; 

CR0N0 OFF; 

END SEQUENCE 
END DEFINE 
END MASCOTIME 



MASCOTime also provides time markers (CR0N0 ON and OFF) to retrieve the 
response time of processing sequences. 



► Generic IDAs: MASCOTime provides the modular composition of existing 
elements to generate a new one, a generic IDA could be an interesting example. 

BEGIN MASCOTIME 

DEFINE ida_01 : GENERIC IDA 

WINDOWS (2) ; 

DEFINE set_0 : CHANNEL 
CAPACITY(20) ; 

TREAD (CST ( 1. 0) ) ; 

TWRITE(CST(1.0)) ; 

END DEFINE; 

DEFINE set_l : SIGNAL 
TREAD (EXP ( 1. 0) ) ; 

TWRITE(CST(2 . 0) ) ; 

END DEFINE; 

ATTACH (WRITE , 0 , set_0) ; 

ATTACH(READ,l,set_l) ; 

END DEFINE 
[CONTINUED — >] 

This code provides a buffer structure for input characters coming from a key- 
board. Each character enters through the window and stored into the channel 
(set(0)). Once every 15 writing of characters, on average, the motor of the IDA 
triggers a sequence of actions: first, the flushes the channel, second writes the 
characters into the extern pooll and finally writes in the intern signal to release 
the window for reading next characters. Figure 3 shows the MASCOT descrip- 
tion of this generic IDA, where sequence of operations and processing delays are 
missing and must be provided by MASCOTime in textual notation. 

There are other interesting MASCOTime building blocks as passive and ac- 
tive servers, IDA motors and other routes that are not here included due to the 
extension of the this text. 



[<— CONTINUED] 

DEFINE motorOl : IDA MOTOR idaOl 
TRIGGER (WRITE, 0 , Bern (15) ) ; 
BEGIN SEQUENCE 
FLUSH(set_0) ; 
WRITE(pooll) ; 
WRITE(set_l) ; 

END SEQUENCE 
END DEFINE 
END MASCOTIME 
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Fig. 3. Generic IDA described with MASCOT diagrams 



6 MASCOTime Simulator 

Since MASCOTime has no utility without a performance evaluation tool, 
a discrete-event simulator prototype has been developed for this purpose. This 
simulator provides enough information to detect the performance behavior of 
the MASCOT models of future system implementations. The interest of our 
prototype relies on the data structure chosen for the simulator construction. 
The objects that the program manages during simulation are isomorphic to the 
MASCOTime components. Since the system modeling has to be flexible, we de- 
cided not to provide an analytical evaluation tool. Thus, it makes no sense to 
translate MASCOTime data structure into traditional performance formalisms. 
In this way, software engineers would feel more comfortable using this perfor- 
mance tool. The new prototype of simulator also includes the integration facilities 
between MASCOTime descriptions and the simulation objects. 

6.1 General Features 

The discrete-event simulator core of MASCOTime prototype is basically con- 
stituted by an asynchronous event processor using a data heap, implemented 
through Java language. Other features of the simulator are: 

— Two operational modes: transient and stationary. 

— In transient mode, the simulator selects a small number of samples. Sam- 
pling may be stored and represented into a graphical tool to determine the 
border of both operational modes, if exist. The main parameters to submit 
a simulation model in transient mode are the amount of sampling and the 
softener window required [14]. 

— In stationary mode, the results of the simulation are in confidence intervals. 
A log file is providing to review the simulation execution. The main parame- 
ters to submit a simulation model in stationary mode are the simulation time 
and the options to avoid the transient time and to resume logging execution. 

— The simulation libraries are organized into classes depending on their func- 
tionality and their privacy. 

— Uniform [0,1] pseudorandom number generator [16], with period 630.360.016. 
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— Main statistical distributions available are: Constant, Exponential, Normal, 
Lognormal, Hypo/Hyper-exponential, Weibull, Uniform [0,1], Uniform [a,b], 
Gamma, Erlang, Pareto, Bernoulli among others [1]. 

— Chronometer option to compute latency times in any sequence of execution 
on MASCOTime objects. 

— Library of Java objects that are isomorphic to the corresponding MASCO- 
Time components. 



6.2 A Simple Example 

MASCOT diagram and code generators, e.g. MADGE, allow software engineers 
to build system models in MDL and also to obtain Ada skeletons from design. 
Once the MASCOT code is provided by such tools, software engineers may 
add the MASCOTime extensions in comments blocks. In this way the original 
functional model remains intact. Then, an automatic interpreter imports the 
annotated MASCOT design and translates it to Java code. This Java code is 
a discrete-event simulator that evaluates the model depending on the param- 
eters submitted. The resulting workflow doesn’t require software engineers to 
know the details of the implementation of the simulator or even to have some 
knowledge about performance modeling with classical formalisms. In order to 
illustrate the performance engineering workflow with our proposal, a simple sys- 
tem was designed with MADGE: a radar system has been represented with 
MASCOT components in figure 4. Five radars send messages to the core of 
the system through a communications channel. Once the information arrives to 
a dispatcher it is shown in the display interface and then stored into the disk 
subsystem. Following the figure 4, the MASCOT MDL code and part of the 
extended MASCOTime block are shown for the radar system. In particular, the 
definition of the three channels involved in the system design: the radar_data 
channel, the disk channel and the buffer channel. 




Fig. 4. A simple example of MASCOT diagrams 
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SYSTEM RADAR.STATION; 

USES RADAR_INFO , CHANNEL, DISPLAY, DISPATCHER, DISK, BUFFER; 

IDA IDA_BUFFER : BUFFER ( PI = DISK_PET.W1 ); 

SERVER S_DISPLAY : DISPLAY; 

ACTIVITY A_DISK : DISK ( PI = DISK_PET.W2 ); 

ACTIVITY A_DISPATCHER : DISPATCHER ( P3 = IDA_BUFFER.W1 , 

P2 = S .DISPLAY. Wl, 

PI = RADAR_DATA.W2 ); 

ACTIVITY RADAR_INF05 : RADAR_INFO ( PI = RADAR.DATA.Wl ); 

[. . .] 

ROUTE DISK_PET : CHANNEL; 

ROUTE RADAR_DATA : CHANNEL; 



{* 

BEGIN MASCOTIME 

DEFINE DISK_PET : CHANNEL 
CAPACITY(20) ; 

TREAD (CST (2.0)) ; 

TWRITE(CST(0 . 5) ) ; 

END DEFINE; 

DEFINE RADAR_DATA : CHANNEL 
CAPACITY(20) ; 

TREAD (CST(0 . 1) ) ; 

TWRITE(CST(0 . 1) ) ; 

END DEFINE; 

[. . .] 

DEFINE IDA_BUFFER : GENERIC IDA 
WINDOWS (1) ; 

DEFINE SET_0 : CHANNEL 
CAPACITY(5) ; 

TREAD (CST (0.3)) ; 

TWRITE(CST(0 . 3) ) ; 

END DEFINE; 

ATTACH (WRITE , 0 , SET_0) ; 

END DEFINE; 

DEFINE M0T0R_1 : MOTOR IDA IDA_BUFFER 
TRIGGER (WRITE, 0, CL0CK(5)); 
BEGIN SEQUENCE 
FLUSH (SET_0) ; 

WAIT (CST (2.0)) ; 

WRITE (DISK_PET) ; 

STOP; 

END SEQUENCE; 

END DEFINE; 

END MASCOTIME 
*} 



END. 
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Table 1. Simulation results for radar_data 



Measurements 




Mean arrival time 


10.020 ± 0.0238 


Mean departure time 


10.020 ±0.0148 


Mean number of messages 


1.525 


% full 


7.628 % 


Mean number of blocked messages for reading 


0.131 


Mean number of blocked messages for writing 


1.162E-5 



With this code we are ready to perform a simulation of the system. First 
we make the simulator work in a special mode to make it determine the end of 
the transient warm up. Then we make the simulator perform a simulation of the 
system discarding the initial transient data. The table below shows the results: 

7 Conclusions and Future Work 

This paper has depicted the integration of the performance engineering tech- 
niques into the software engineering arena through an isomorphic description 
of the performance behaviour and a discrete-event simulator prototype. The 
approximation chosen minimizes the interference in the software design method- 
ology by means of performance constraints annotations. In particular, MASCOT 
design methodology, which has been used for twenty years in European Defence 
companies, has been extended to MASCOTime, our proposed annotated version 
for this traditional methodology. Even though several tools have been built to 
generate automatically system designs from MASCOT diagrams, none of these 
facilities has been extended to incorporate performance information of such sys- 
tem designs. Particularly, MADGE tool generates Ada code and textual MDL 
notation from a graphical user interface representing the components that soft- 
ware engineers are using to build the software models of future systems. These 
components are basically activities, intercommunication data areas (IDAs) and 
servers. All MASCOT components are functionally connected through windows, 
ports and paths. Thus, MASCOTime takes advantage of the functional skeleton 
of the system model to add performance constraints on every component of the 
design. In order to minimize the interference of software engineering tasks, all 
the MASCOTime extensions are code comments in MDL. Since the goal of per- 
formance engineering is to evaluate the system model, a discrete-event simulator 
for MASCOTime has been prototyped. Although simulation is only an approx- 
imation, it is more flexible than using analytical/numerical solvers which would 
be very restricted for their application to complex software designs. Therefore, 
there is no necessity to transform the MASCOTime structure to a traditional 
formalism and then evaluate the transformed model. Our proposal consists on 
building the simulator with objects that are isomorphic to the MASCOT com- 
ponents. Thus, the discrete-event simulator has been implemented in Java code 
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that provides other advantages as portability. An interpreter of the MASCO- 
Time extension has been also built to map design models to simulation objects. 
Some examples of MASCOTime code and the execution of the discrete-event 
simulation have also been shown. The prototype that has been implemented 
must be tested by final users in order to verify its real applicability. In order 
to get the industrial validation of the prototype, it is going to be informally 
tested by MBDA, formerly known as Matra British Aerospace. This prototype 
should be extended in order to increment the approach alternatives to solve an- 
alytically some simple components by decomposition-aggregation and then the 
whole system through hybrid techniques. Depending on the user validation, we 
may integrate MASCOTime in MADGE tool including the GUI interfacing. 
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Abstract. This paper describes the tool CASPA, a new performance 
evaluation tool which is based on a Markovian stochastic process alge- 
bra. CASPA uses multi-terminal binary decision diagrams (MTBDD) to 
represent the labelled continuous time Markov chain (CTMC) underly- 
ing a given process algebraic specification. All phases of modelling, from 
model construction to numerical analysis and measure computation, are 
based entirely on this symbolic data structure. We present several case 
studies which demonstrate the superiority of CASPA over sparse-matrix- 
based process algebra tools. Furthermore, CASPA is compared to other 
symbolic modelling tools. 



1 Introduction 

Symbolic data structures, such as binary decision diagrams (BDD) [3] and vari- 
ants thereof, have proven to be suitable for the efficient generation and compact 
representation of very large state spaces and transition systems. In [13] it has 
been shown that in the context of compositional model specification formalisms 
such as process algebra, the size of the symbolic representation can be kept 
within linear bounds, even if the underlying state space grows exponentially. 
The key to such compact representation is the exploitation of the compositional 
structure of a given specification [14, 7, 24] . It is also known that in addition to 
functional analysis, performance analysis and the verification of performability 
properties can also be carried out on such symbolic representations [17, 24]. 

In this paper, we describe the new tool CASPA which offers a Markovian 
stochastic process algebra for model specification. CASPA generates a sym- 
bolic representation of the underlying labelled CTMC, which is based on multi- 
terminal BDDs (MTBDD), directly from the high-level model, without generat- 
ing transition systems as an intermediate representation. In addition to specify- 
ing the model, the CASPA modelling language allows the user to specify different 
types of performance and dependability measures of interest. Numerical analy- 
sis and computation of measures are also carried out directly on the symbolic 
representation of the transition rate matrix of the underlying CTMC. To our 
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knowledge, CASPA is the first stochastic process algebra tool whose implemen- 
tation relies completely on symbolic data structures. 

1.1 Related Work 

Among other tools which are based on symbolic data structures are the model 
analyser SMART [4] and the probabilistic model checker PRISM [20, 21]. 
While SMART relies on multi-valued decision diagrams and matrix diagrams, 
PRISM - like CASPA - is based on multi-terminal binary decision diagrams. In 
Sec. 4, we compare CASPA to PRISM, mainly with respect to compactness of 
representation and effects of state space ordering. We also performed experi- 
ments with SMART, whose state space generation component seems to be even 
faster. However, we deliberately do not compare the numerical analysis com- 
ponent of SMART to that of CASPA, since this would basically boil down to 
a comparison of the algorithms of SMART and PRISM, which is not our focus 
here. In Sec. 4.1 we also compare CASPA to the work presented in [8], which 
is based on multi-valued decision diagrams and matrix diagrams. With respect 
to symbolic tools for stochastic process algebra, we also mention the work [11], 
where a PE PA specification (derived as an intermediate language from a UML 
specification) is used as input for PRISM. 

1.2 Organisation of the Paper 

The paper is organised as follows: In section 2 we introduce CASPA’s speci- 
fication language and give an overview of its architecture. Section 3 explains 
how the specification is translated to MTBDDs. In section 4 we demonstrate 
the usefulness of our approach by means of several case studies, which includes 
a comparison with other tools. Section 5 summarises our results and concludes 
with an outlook on future work. 



2 Specification Language and Tool Architecture 

In this section we briefly explain how a system and its measures of interest can be 
described in CASPA. We discuss an example specification and give some details 
on the tool’s architecture and implementation. 

2.1 System Specification 

CASPA’s specification language is derived from the stochastic process algebra 
TIPP [15, 12]. It provides operators for prefixing, choice, enabling, disabling, 
parallel composition and hiding. Infinite (i.e. cyclic) behaviour is specified by 
means of defining equations. All actions are associated with an exponential de- 
lay, which is specified by a rate parameter. The technique used for symbolic 
model representation (cf. Sec. 3) works only for finite state spaces. Therefore 
the grammar of the input language is such that recursion over static operators 
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(1) /* Rate and constant definitions */ 

(2) rate xi = 0.5; 

(3) rate gamma = 5; 

(4) rate mu = 0.3; 

(5) int max = 3; 

(6) /* System specification */ 

(7) System := (P(0) | [] I P(0)) I [b] I (hide a in Q(10)) 

(8) Q(m [10]) := [m > 0] -> (a,xi) ; Q(m-l) 

(9) [m = 0] -> (b,mu); Q(10) 

(10) P (n [max]) := [*] -> (b, gamma); P(n) + (c, gamma); stop 

(11) [n > 0] -> (d,n*mu) ; P (n-1) 

(12) [n < max] -> (a, 0.3); P (n+1) 

(13) /* Measure specification */ 

(14) statemeasure XXX (P{l}(n > 0) & !P{2}(n = max)) | Q(m = 4) 

(15) meanvalue YYY P{2}(n) 

(16) throughputmeasure ZZZ a 



Fig. 1 . Example CASPA specification 



(i.e. parallel composition and hiding) is not allowed, which ensures that the 
underlying state space is finite. 

The specification language allows the specification of parameterised pro- 
cesses, i.e. processes which carry one or more integer parameters. This feature 
is very useful for describing the behaviour of queueing, counting, or generally 
indexed processes. Within a parameterised process, the enabling of actions may 
be conditioned on the current value of the process parameters. In CASPA it is 
possible to define both rate and parameter constants. Parameters are always 
integer numbers, whereas rates are real numbers. 

2.2 Example 

We now discuss a small example (see Fig. 1). This specification has no special 
meaning, its only purpose is to introduce the language elements of CASPA. In 
lines (2) to (4) we find the definition of specific rate values, in line (5) a global 
parameter constant is defined. Lines (7) to (12) contain the system specifica- 
tion. Line (7) shows both possibilities to define parallel processes: The two P(0) 
processes are composed in parallel without interaction, i.e. all their actions are 
performed independently of each other. In contrast, Q (10) is composed in par- 
allel with the two former processes in a synchronised way, i.e. action b must be 
performed by one of the P-processes and the Q-process at the same time. The 
synchronisation semantics is the same as for TIPP [15, 12]. In line (7) we also 
find the hiding operator: Action a in process Q is hidden from the environment 
and replaced by the special silent action tau. In line (8) we see an example 
of guarded choice: Action a can be performed if the value of parameter m is 
greater than zero. In line (10) we see a guarded choice whose test consists of *, 
which means the branch can be taken regardless of the actual parameter value. 
In lines (8) and (10) the maximum value of the respective parameters is given: 
For process P we chose a global constant max, for process Q the maximum value 
10 is given explicitly. As for every process parameter such a maximum value 
has to be defined, the finiteness of the underlying state space is guaranteed. In 
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Fig. 2. Tool architecture 



line (10) a choice between (b, gamma) ; P(n) and (c, gamma) ; stop is given. As 
all actions have exponential delay the choice of which action is actually taken 
corresponds to a race condition (as for stochastic Petri nets). In line (11) we see 
that rates can be arithmetic expressions, which makes it possible to define rates 
that are dependent on actual parameter values, similar to marking dependent 
rates in stochastic Petri nets. Finally, in lines (14) to (16) we find examples of 
measure specifications. We see that state measures can contain Boolean expres- 
sions with the usual connectives conjunction (&), disjunction (|) and negation 
(!). The clause (P{l}(n > 0) & !P{2}(n = max)) characterises states in which 
parameter n of process P{ 1} is greater than zero, and parameter n of process 
P{2} is smaller than the maximum value, where P{i} expresses that we are inter- 
ested in the i-th of the two P processes. A mean value will return the expected 
value of the specified process parameter (in line (15) it will be the mean value 
of parameter n of process P{ 2}) , and a throughput measure will compute the 
throughput of the given action (in line (16) this is action a). 

2.3 Tool Architecture 

CAS PA is written entirely in C. The lexical analyser was realised using the tool 
flex, the parser was written in bison. The symbolic engine was implemented 
using the BDD-library CUDD [25] and the hybrid numerical solution methods 
developed by Dave Parker [22] within the context of the tool PRISM. The tool 
architecture consists of three major parts [26], as shown in Fig. 2. 



User Interface. Up to now, CASPA has only a textual user interface. A typical 
call of the tool consists of indicating the file name that contains the system 
and measure specification, the analysis method, parameters for the numerical 
analysis and information about the verbosity level. An example call looks as 
follows: 

caspa -v 1 -r -T -a TRANSIENT 100 ftcs.cas 

The textual user interface is also used to present the results of the tool, i.e. 
number of states, information about the size of the symbolic representation, 
computation times, results of numerical analysis, etc. Additionally, CASPA can 
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generate output that makes it possible to visualise the state space using the tool 
davinci [6], or for any graphical tool that can handle the .dot [1] format. 



Tool Driver. From the command line the specification file is passed to the tool 
driver. It parses the system and the measure specification, translates them into 
their parse graphs and passes the results to the state space manager. 

State Space Manager. The state space manager generates (from the parse 
graphs of the system and measure specification) the MTBDD representation of 
the labelled CTMC, resp. of the measures. It can perform reachability analysis, 
and manipulates the MTBDD data structure to allow for efficient numerical 
analysis (cf. section 3). 



Numerical Engine. The numerical engine computes the vector of state proba- 
bilities. Several well-known numerical algorithms for both steady-state and tran- 
sient analysis are implemented. The algorithms and their implementations are 
taken from PRISM, for their detailed description see [22]. The user can set the 
parameters of the algorithms, such as accuracy or maximum number of itera- 
tions. 

3 Markov Chain Generation, Representation 
and Numerical Analysis 

In this section, the approach of CASPA for directly mapping the process terms 
to MTBDDs is presented. Note that a CTMC is never constructed explicitly, 
only its symbolic encoding. A more detailed exposition of this translation can 
be found in [18]. We also briefly describe how the specified measures are related 
to the Markov chain representation and how the measures are computed. 

3.1 Basis for Symbolic Representations 

In this subsection we briefly introduce the basics of symbolic state space repre- 
sentation. An exhaustive account of this can be found in [24]. 



Multi-terminal Binary Decision Diagrams. MTBDDs [10] (also called al- 
gebraic decision diagrams (ADDs) [2]) are an extension of binary decision dia- 
grams (BDDs) [3] for the canonical graph-based representation of functions of 
type JB n i— > 1R. We consider ordered reduced MTBDDs where on every path from 
the root to a terminal vertex the variable labelling of the non-terminal vertices 
obeys a fixed ordering. 
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Representation of CTMC. MTBDDs can be employed to compactly repre- 
sent labelled CTMCs. Let s 1 be a transition of a labelled CTMC, where s 
is the source state, a is the action label, A is the rate and t the target state of the 
transition, then this transition is encoded by a bit string, ai, ..., a nL , si, ti, ...s„ s , 
t ns where 



— ai, a riL encode the action label a 

— si, s ns encode the source state s and 

— ti, ...,t ns encode the target state t 

In the MTBDD, there is a Boolean variable for each of these riL + 2 ■ ns bits, 
and the rate A will be stored in a terminal vertex. One of the main issues in 
obtaining a compact MTBDD representation is the choice of an appropriate 
variable ordering. A commonly accepted heuristics is an interleaved ordering for 
the variables encoding source resp. target states, i.e. the ordering of the MTBDD 
will be: ai -< <22 A ... A a„ L -< Si -< <1 -< S 2 A t2— A s ns -< t ns . This ordering, 
together with a proper treatment of the parallel composition operator, ensures 
the compactness of the resulting MTBDD [13, 24] 



Translating the CASPA-Specification to MTBDDs. The basic procedure 
is as described in [18]. Here we only discuss the translation of parameterised pro- 
cesses, i.e. we describe our approach of how to represent parameterised processes 
symbolically. The parse graph structure describes the transitions depending on 
the parameter values, thereby also describing the possible changes of the pa- 
rameter values. In CAS PA the definition of the transitions is separated from the 
change of parameters. Let A be a parameterised process, then there is in X’s 
parse graph exactly one node, called PARAM node, which describes the pos- 
sible transitions. The condition list of a guarded choice is stored in this node. 
Furthermore, the parse graph may contain several nodes that store the possible 
changes of the parameter values, called PARAMDEF nodes. In order to gener- 
ate from this information the actual MTBDD representation of a parameterised 
process, it is necessary that the generation algorithm keeps track of the current 
parameter value, which information is taken from the PARAMDEF nodes. The 
PARAM node serves to determine which transitions are possible in view of the 
current parameter values. For every satisfied condition, the successor process is 
determined, and the overall representation of a parameterised process is then 
a choice over all possible successor processes. 

3.2 Data Structures for Measure Representation 

For state measures and mean values the main task is to identify the states, 
resp. their binary encodings, that are relevant for the measure. As many states 
may contribute to a particular measure, we employ BDDs for a compact repre- 
sentation of the state sets. 




Symbolic Performance and Dependability Evaluation with the Tool CASPA 



299 



(1) /* Rate and constant definitions */ 

( 2 ) ... 

(3) /* System specification */ 

(4) Process := Queue (0) 

(5) Queue (n [3]) := [n >= 1] -> (serve, mu); Queue (n-1) 

(6) [n < 3] -> (arrival , lambda) ; Queue (n+1) 

(7) [*] -> (f ail , gamma) ; Repair 

(8) Repair := (repair ,rho) ; Queue (0) 

(9) /* Measure specification */ 

(10) statemeasure Queuenotfull Queue (n < 3) 

(11) meanvalue Fill Queue (n) 

(12) throughputmeasure Service serve 



Fig. 3. Example specification 



State Measures. For a given state measure, we first generate its parse graph. 
Since the state measure is related to one or several process names, each node of 
the system’s parse graph that contains a process which is referenced in the state 
measure will get a pointer to the respective node in the measure’s parse graph. 
On generation of the MTBDD for the system, the encoding of each process that 
contains such a pointer is written to the correspondig measure’s sub-BDD. After 
the complete generation of the system’s MTBDD representation, the measure’s 
overall BDD is generated by applying the Boolean operators in the measure’s 
parse graph. 



Mean Values. For mean values we have to generate for each possible parameter 
value a BDD that encodes the states in which the parameter has exactly that 
value. Since processes can have several parameters (and since processes are com- 
posed in parallel with other processes), there may be many states in which the 
parameter of interest has the same value (whereas the values of the remaining 
parameters, or the states of the other processes, may change). After the genera- 
tion of the system’s MTBDD representation, the measure BDDs are added up, 
thereby weighing each BDD with the associated parameter value. The result is 
an MTBDD in which every state encoding is related to its respective parameter 
value. 



Throughput Measures. Throughput measures are not related to specific pro- 
cesses. Therefore no extra BDD for them needs to be generated. The system’s 
MTBDD representation is restricted to the action label whose throughput is to 
be determined, and the target states are abstracted away. The result is then an 
MTBDD consisting of the states in which the relevant action is enabled, weighed 
with the respective transition rates. 

3.3 Example 

We will clarify the concepts of generating an MTBDD representation for pa- 
rameterised processes and relating encodings and measures by means of the 




300 



Matthias Kuntz et al. 









(1) 


s 

> 


Process 




£ 






(2) 




Queue 




1 


0 












Queue 


n: 3 




n < 3 n 


>=1 


. 



arrival 

lambda 


PREFIX 


serve 

mu 


PREFIX 


1 (8)& 


J 


(9) 


Queue 


1 


Queue 


3 


n + 1 


1 


n- 1 


>L 



fail 

gamma 



repair 

rho 



Repair 



Fig. 4. Parse graph for the specification in Fig. 3 



example shown in Fig. 3. The parse graph of the specification can be found 
in Fig. 4. In the PARAMDEF node (2) the parameter value is initialised to 
zero. In the PARAM node (3), when it is visited for the first time, the con- 
ditions of the first and the third field are fulfilled, therefore we can generate 
the MTBDD for their respective successor nodes. To generate the successor 
node we use the information about the actual parameter value and the change 
of parameter values of the PARAMDEF nodes. In the initial case the suc- 
cessor processes are (arrival , lambda) ; Queue (1) and (f ail, gamma) ; Repair. 
For Queue (1) and Repair we then compute again the successor processes, and 
so on. For Queue (1) all three conditions are fulfilled and we have three suc- 
cessor processes, namely (arrival , lambda) ; Queue (2), (serve, mu) ; Queue (0) 
and (fail, gamma) ; Repair. For the latter two, the successor nodes are already 
known, whereas for Queue (2) the successor processes still have to be computed. 
The overall MTBDD representation is obtained as a choice between the MTBDD 
representations of all successor processes which were found. 

For the state measure Queuenotfull of Fig. 3 the states for Queue (0), 
Queue (1) and Queue (2) are relevant. Therefore, on generation of the respec- 
tive MTBDDs the encodings of these states are copied to the measure BDD. For 
the mean value measure Fill an MTBDD is constructed where the encoding of 
each reachable state leads to the corresponding value of parameter n. Assuming 
that states are encoded as shown in Fig. 5 (left), the resulting MTBDD for this 
mean value measure looks as shown in Fig. 5 (right). 

3.4 Numerical Analysis and Computation of Measures 

Our experience shows that MTBDDs are a suitable data structure for the com- 
pact and efficient storing of extremely large state spaces [24]. However, it is 
known that purely MTBDD-basecl numerical analysis is very slow [9]. In [22], it 
was shown that it is possible to combine the advantages of sparse data structures 
(efficient matrix- vector multiplication) with those of MTBDDs (compact model 
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Fig. 5. State encoding (left) and MTBDD for measure Fill (right) 
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Fig. 6. Configuration of a single computer for the fault-tolerant multi computer system 
according to [23] 



representation), leading to so-called hybrid offset-labelled MTBDDs. These data 
structures and the associated numerical algorithms were implemented in the 
stochastic model checker PRISM [20, 21]. Several case studies using PRISM 
proved the efficiency of the data structures and algorithms, therefore we decided 
to adopt this approach for CASPA. 

In PRISM, and therefore also in CASPA, numerical algorithms for both steady- 
state and transient analysis are implemented. For steady-state analysis Power, 
Jacobi, Pseudo-Gauss-Seidel and their overrelaxed versions can be used. For 
transient analysis uniformisation is employed. 

4 Case Studies 

In this section we show the applicability of CASPA by means of several case 
studies: All results were computed on an Intel Pentium IV 3 GHz CPU with 
1024 MB RAM, running SuSe 9.0 Linux. 

4.1 Fault Tolerant Multi Computer System 

This example is based on a case study described originally in [23] and used again 
in [8]. Due to the different modelling formalisms (stochastic activity networks 
versus stochastic process algebra), some re-modelling effort was required. The 
original model consists of n computers each of which has the following compo- 
nents: 
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— 3 memory modules, of which 2 must be operational 

— 3 CPU units, of which 2 must be operational 

— 2 I/O ports, of which 1 must be operational 

— 2 error-handling chips, which are not redundant. 

Each CPU and I/O-port consists of 6 non-redundant chips. Each memory module 
possesses 41 RAM chips, of which at most 2 may fail, and 2 interface chips that all 
must be operational. A computer fails, if one of its components fails. The overall 
system is operational if at least one computer is operational. A diagramatic 
overview can be found in Fig. 6. 



Results. The measure we are interested in is the survival probability of the 
system. All results were computed using uniformisation with relative precision 
10 -6 . The computation times, including model construction, numerical analy- 
sis and measure computation, range from less than one second for the smallest 
configuration (889 reachable states) to about 30 sec for the largest configuration 
(750,000 reachable states). In Fig. 7 we see the survival probability for differ- 
ent system configurations: Cl is the configuration of the original system (i.e. 
consisting of two computers with three memory modules each) which has about 
750,000 reachable states. C2 consists of two computers with only one memory 
module each, and has 2152 reachable states. C3, which is identical to C2 but 
possesses no redundant 1/0 port, has only 889 reachable states. Finally C4 has 
the same configuration as C2, but consists of 3 computers instead of 2, hav- 
ing 120,000 reachable states. The survival probability, dependent on the mission 
time, is shown in Fig. 7. 

Our results are not directly comparable to the ones reported in [8] (where 
multi-valued decision diagrams and matrix diagrams are employed as the un- 
derlying data structures): Firstly, we consider slightly different system configu- 
rations, and secondly, we do not exploit lumpability (which is due to replicated 
components). However, it is interesting that [8] reports a computation time of 
15.5 sec per iteration for a 463,000 state model, while we measured only 0.12 sec 
per iteration for the 750,000 state model (the machine speeds are almost identi- 
cal, and ours has only one third of the memory) . 

4.2 Kanban System 

For this case study we computed steady-state probabilities for the well-known 
Kanban example (originally described in [5]). We model a Kanban system with 
four cells, a single type of Kanban cards, and the possibility that some workpiece 
may need to be reworked. The performance measures we compute are the average 
number of cards in each cell and the throughput of parts with and without rework 
for each cell. 



Results. In Fig. 8 (left) we see the average fill of cells 1 to 4, depending on the 
number of cards N. Note, that due to the symmetric nature of the model, the 
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Fig. 7. Survival probability of fault-tolerant multi computer system 




Fig. 8. Left: Average fill of cells 1 to 4. Right: Throughput of workpieces for cell 1 



fill of cell 2 and 3 is identical, therefore the two curves are superposed. Fig. 8 
(right) shows the throughput measures for cell 1 dependent on the number of 
cards. 

Details about state space size, MTBDD size and time needed for computing 
the measures can be found in Table 1 (top). The analysis method used here was 
Pseudo-Gauss-Seidel (which was the most efficient one), with relative precision 
lCT 6 . 

As a comparison, TIPPtool [12] takes more than 4 hours just to generate 
the state space of the Kanban model with N = 4 (on the same machine), not 
including numerical analysis and measure computation. This huge difference can 
be explained by the fact that TIPPtool needs to traverse all transitions of the 
underlying labelled Markov chain explicitly in a sequential fashion, while CASPA 
performs a symbolic product space construction followed by a symbolic reach- 
ability analysis (where the latter works on sets of states and not on individual 
states) . 

We now compare the experimental results obtained with CASPA to those 
obtained with PRISM, which are shown in Table 1 (bottom). We observe, that 
the number of MTBDD nodes (column “final” ) is not the same for both tools: 
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Table 1. Results for Kanban system 
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a including reachability analysis 

b including measure computation (in the case of CASPA) 



While CASPA constructs smaller MTBDDs for small values of N, the converse 
is the case for larger values of N. We attribute this phenomenon partly to the 
different state space ordering as caused by the state space generation algorithms 
of the two tools, and partly to the fact that CASPA’s symbolic representation 
includes the encoding of the action labels which is not the case for PRISM. In 
the case of CASPA, the peak number of MTBDD nodes during the construction 
process (column “peak”) is much higher than the final number of nodes, but it is 
still extremely small compared to the size of the state space. Since PRISM does 
not give peak numbers, the corresponding positions are marked with a “?”. State 
space construction (column “MTBDD Generation”) is faster in CASPA, but this 
is not really significant since state space construction is not the bottleneck. The 
number of iterations performed is always smaller in CASPA, which again seems 
to be due to the state space ordering (we emphasize at this point, that finding 
the optimal state space ordering is an NP-complete problem, therefore one can 
only resort to heuristics as described e.g. in [13]). A comparison of the total 
times for numerical analysis is not of interest for two reasons: Firstly, CASPA- 
times include measure computation while PRISM-times do not. Secondly, the 
numerical engine of CASPA is taken from PRISM, so the implementations are 
practically identical. 
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Table 2. Results for Polling system 
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4.3 Polling System 

As a third case study we consider a polling system, consisting of a server and N 
stations which are served in a cyclic fashion. This system was originally described 
in [16] and has since been frequently used as a standard benchmark. The results 
are shown in Table 2 (where the numerical method was again Pseudo-Gauss- 
Seidel). We observe that the MTBDDs generated by CASPA are up to 36% 
larger than the ones generated by PRISM, and that CASPA always needs more 
iterations. However, quite surprisingly, the time per iteration is always smaller 
in the case of CASPA. 



5 Conclusions 

In this paper we have presented CASPA, a stochastic process algebra tool which 
realises a completely symbolic approach from model construction to the com- 
putation of performance and dependability measures. CASPA implements an 
MTBDD-based state space generation scheme and allows the computation of 
transient and steady-state measures on the basis of well-established numerical 
algorithms. 

We carried out systematic tests on many case studies: In addition to the ones 
given here, several queueing models, a mainframe system with software failures 
and a wireless communication network were analysed using CASPA. The results 
for all case studies are very positive, both state space generation and numerical 
analysis have shown to be highly efficient. CASPA is clearly superior to sparse- 
matrix based tools such as TIPPtool, and it compares well to other symbolic 
tools such as PRISM. 

We are currently working on extending CASPA with a symbolic stochas- 
tic model checking engine. We plan to support the powerful action-based logic 
sPDL [19] which enables the user to define complex performance and depend- 
ability requirements in a formal and concise way. 

Last but not least, in order to further increase its usability, in the future 
CASPA shall be equipped with a graphical user interface. 
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Abstract. This paper presents a testing method for an agent system 
against its specification described with Statecharts. Here, an agent sys- 
tem means an implementation of an agent application. Its testing method 
generates test sequences from the specification and checks whether the 
agent system behaves in accordance with the specification by execut- 
ing the test sequences. For specification-based testing, we have extended 
Statecharts in order to describe the behavior of an agent system accord- 
ing to the concept of Agent UML. Then, we propose an approach to 
generating test sequences from the extended Statecharts. Our approach 
makes effective use of partial order methods for considering representa- 
tive sequences of equivalent classes divided from all possible sequences. 
Therefore, we can efficiently manage a large number of possible sequences 
caused by the agents’ autonomy. As a result, we can reduce the number 
of test sequences and the number of executions to be tested. 



1 Introduction 

Verification of the agent systems to be used on the Internet is a critical issue be- 
cause independently developed agent systems make use of each other, and bugs 
in a single agent system may affect a number of other systems. Moreover, one of 
the characteristics of agent systems is the autonomy of agents, which allows an 
agent to execute its behavior based on its own decisions. This autonomy is con- 
sidered to consist of nondeterministic choices in its behavior, and agent systems 
have a large number of possible execution sequences. That is, agent systems are 
concurrent programs with nondeterministic nature. Therefore, applying a testing 
method to concurrent systems is one of the predominant approaches to verifying 
agent systems. Its main issue is how to effectively cover the large number of 
possible sequences [I] [2]. 

In previous agent modeling frameworks like Agent UML [3] [4], behaviors 
of agent systems have been described with message sequence charts. However, 
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message sequence charts describe a subset of all possible behaviors, so a detailed 
and elaborate specification is required for testing agent systems accurately. Stat- 
echarts may be a viable candidate since Statecharts allow us to describe all pos- 
sible behaviors [5] [6]. However, Statecharts are still inadequate for describing 
agents’ behaviors based on autonomy. 

In this paper, we propose an approach to generating test sequences for testing 
agent systems based on a Statechart specification. First, we extend Statecharts 
to allow flexible description of agents’ behaviors. Then, we present a method 
to generate test sequences from the extended Statecharts. The testing method 
uses a reduced reachability analysis based on partial order methods in order to 
effectively deal with the large number of all possible sequences. It constructs 
a reduced reachability graph from which the representative sequences of equiva- 
lent classes can be generated as substantial test sequences. Then, each equivalent 
class can be separately generated from such a representative sequence. 

The rest of this paper is organized as follows. In Section 2, we briefly describe 
related works. Section 3 presents our method to extend Statecharts so that they 
are adequate for describing agent systems. In Section 4, we explain the process 
of generating test sequences from the extended Statecharts. In Section 5, we 
conclude the paper and mention directions for future work. 



2 Related Works 

2.1 Specification of Agent Systems 

In recent years, there has been much research on development methodology 
for agent systems. For example, Tropos [7], INGENIAS [8] and GAIA [9] have 
proposed methods for agent-oriented software engineering. As with conventional 
software development, they use systematic processes to develop agent systems, 
and the processes cover requirements, designs and implementations. However, 
these development processes are based not on concrete agents but on abstract 
and logical roles of agents, and thus testing an implemented agent system is 
out of the scope of such work. In the design phase of the above agent-oriented 
methodologies, an extended sequence diagram is used as a visual description. 
The extended sequence diagram is defined In the agent UML [3] [4] . It deals with 
roles as basic elements and describe interactions between roles. Moreover, they 
support extended interactions for concurrent threads: inclusive or, exclusive or 
and and. However, sequence diagrams are scenario-based descriptions, and they 
present abstract behaviors of systems. 

2.2 Specification-Based Testing of Concurrent Programs 

A common approach to generating test sequences by managing concurrency is the 
flattening method [10] [11]. From a given specification, it constructs a reachability 
graph to present all interleavings of concurrent events and generates all possible 
sequences as test sequences from the reachability graph. However, the critical 
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limitation of this approach is the explosion problems of states and sequences, 
since a reachability graph presents all possible behaviors of concurrent systems. 
Moreover, having many test sequences by interleavings requires high costs of test 
execution. These limitations become more critical in agent systems because they 
have a huge number of possible execution sequences. 

The reduced reachability analysis in [2] and constraints-based testing in [1] 
are two approaches to alleviating the explosion problems in test sequence genera- 
tion. In the reduced reachability analysis , representative sequences are generated 
as test sequences by constructing a reduced reachability graph that presents one 
of all possible interleavings of concurrent events. However, it does not consider 
other sequences equivalent to each representative sequences. Constraints-based 
testing uses the sequencing constraints that a concurrent program must satisfy in 
all of its states. Test sequences are generated by covering sequencing constraints. 
However, it is difficult to acquire sequencing constraints from a specification since 
they are general properties of a concurrent program. 

3 Extending Statecharts for Agent Systems 

3.1 Description of Agent Systems with Conventional Statecharts 

Statecharts [5] [6] is a visual and behavioral specification languages that are suit- 
able for modeling reactive systems. Statecharts is defined as an extension to the 
FSM with features such as concurrency and broadcast communications. In Stat- 
echarts, state transitions triggered by events describes the dynamic behaviors, 
and those extended features facilitate the description. In this section, we describe 
agent systems using conventional Statecharts and then discuss on the necessity 
of extending the Statecharts to make them effective for agent systems. 

Agent systems are of course concurrent systems that work through many 
message exchanges among autonomously behaving agents. We should take this 
characteristics into consideration in describing agent systems. First, concurrent 
agents can be directly described with concurrent AND components in State- 
charts. Next, a large number of interactions among concurrent agents can be 
described by using broadcast communication. 

The definition of broadcast communication is briefly phrased as follows: for 
the transition t with the label ( e ex /ei n ) : the external event e ex triggers t and 
the internal event ei n occurs. Then, d n is broadcasted to the entire system, 
and transitions with the label including (ej n ) are also triggered in the current 
state [6]. However, the interactions in an agent system are generally represented 
by messages. Moreover, an agent system has many decision points established not 
only by its environments but also by its autonomy, and messages are generated 
as the results of the decisions. Therefore, we manage the decision point DP as 
an external event and express its resultant message msg as an internal event. In 
result, the label of the sending point becomes the form ( DP/msg ), and the label 
of the receiving point becomes the form (msg). 

Figure 1 shows the marketplace example specified with the conventional Stat- 
echarts. Two concurrent agents, Buyer and Shop , are presented and each agent 
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Fig. 1. Example of the Statecharts specification for a marketplace system 



reacts to events that express decision points or messages: for understandability, 
capitalized words indicate decision points and lower-case words indicate mes- 
sages. To explain interactions between agents, consider the configuration [Ready, 
Waiting ], which is one of the system’s global states. When ASK_PRICE is de- 
cided in the configuration, the transition ( ASK_PRICE/ask_price ) is triggered 
in Buyer , and then ask_price occurs and it is broadcast to the entire system. In 
this situation, the transition ( ask_price ) is also triggered in Shop. In result, the 
configuration changes from [Ready, Waiting] to [ Waiting, Replying] as the result 
of interactions by ASK_PRICE. 

3.2 Extended Features for Agent Systems 

Although conventional Statecharts can represent both concurrency and commu- 
nication, they are insufficient for describing agent systems due to the systems’ 
characteristics. For example, the agent system in Figure 1 consists of a single 
buyer and a single shop, but an actual agent system consists of multiple buyers 
and shops that have similar behaviors. Although the generic charts in the con- 
ventional Statecharts reduce duplicated presentation, they cannot present the 
autonomy of agents and diverse interactions between agents. Therefore, as with 
other agent-oriented methodologies, we extend Statecharts by focusing on the 
roles of agents and the various interactions. Moreover, we extend certain states 
in Statecharts so that they can memorize interacting agents. In this paper, we 
assume that one agent has only one role and is implemented with one thread. 



Role-Based Description. Roles are the logical components of agent systems. 
Agent systems actually consist of diverse concrete agents, but some agents among 
them can have the same behavior, that is, the same role. In the design phase, it 
is not necessary to describe all duplicated agents, and in fact such description is 
also impossible because we cannot determine the number of concrete agents for 
one role in advance. Therefore, we extend an AND component into a role-based 
component as follows: 
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Fig. 2. A marketplace system specified with extended Statecharts 



— Role-Name (Agent-Set) 

• Role-Name : name of agent role 

• Agent-Set : the set that contains id of all concrete agents of the role 

From each role, concrete agents belonging to it are instantiated by giving id 
of such a agent to the parameter in Role-Name. For example, Buyer(X) is one 
basic component and one role in Figure 2. If X = {1, 2}, concrete agents with 
that role are Buyer ( 1 ) and Buy erf 2), and they show the same behavior such that 
a buyer asks an item’s price to all shops and buys the item from a shop. 



Various Event Types. In an agent system, agents can have diverse interactions 
with different relationships between the role of sender and the role of receiver. 
Even if concrete agents have the same role, only some agents belonging to it can 
be related to a given specific interaction. That is, each interaction is related to 
one, some or all concrete agents with the same role. For example, when a shop 
replies to the specific buyer asking the item’s price, the shop has no relation 
with the other buyers. To describe this variety of interactions between role- 
based components, we define new event types and some reserved keywords for 
communication . 

— Event (Senders, Receivers) 

• Sender : ids of specific sending agents 

• Receiver : ids of specific receiving agents 

— Reserved Keywords for Sender and Receiver 

• self : one specific agent (the id of itself) 

• -[agent] : all agents except agent 

• all: all agents 

The fundamental form of events is event(a:X, b:Y). This means that a con- 
crete agent Role-X(a) sends event to a concrete agent Role-Y(b). However, re- 
served keywords or variables can be used instead of concrete agents, since the 
specification is role-based description. In Figure 2, let X={1, 2} and Y={1, 2}. 
Then, ask-price (self, all) in Buyerf 1 ) implies that Buyerf 1 ) sends ask-price (1, all) 
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Fig. 3. Specification for marketplace example with actual parameters: this specifica- 
tion follows the semantics of conventional Statecharts 



to all shops. REPLY (self ,i:X) in Shop (2) implies that Shop(l) sends REPLY(2,1) 
and REPLY(2,2) to Buyer(l) and Buyer(2) respectively. On the other hands, 
-[agent] is used as follows. Let Role(Z) be a role and Z={ 1, 2, 3}. Then, for 
Role(2), event(i:X,-[ self],) expresses both event(i:X, 1) and event(i:X, 3). 



Agent Memory in States. Because agent systems have a property that agents 
can be dynamically created and eliminated, the participant agents in commu- 
nications should often memorize the information about other participants. For 
example, a shop should reply only to a specific buyer asking a price. Therefore, 
we extend states with the agent’s id: State(id). For example, REPLY(self, i:X) 
in Shop(Y) is the reply to ask_price(i:X, all), and ’i:X’ is here set to the same 
agent as Buyer (i) through the state Replying (i:X). 



3.3 Comparison of Modeling Agent Systems 

For comparison of extended Statecharts and conventional Statecharts, let’s con- 
sider the specification of the marketplace system described with conventional 
Statecharts: the specification in Figure 3 shows the same behaviors as the spec- 
ification in Figure 2 under the restriction, X — {1,2} and Y = {1, 2}. 

We have introduced three extended features for agent systems and the char- 
acteristics of them are to remove overlapped description in a specification. Three 
extended features, respectively, fold an overlapped concrete agents, events, and 
states with parameters. For example, Shop(l) and Shop(2) in Figure 3 are 
folded into Shop(X) in Figure 2. Thus, ASK_PRICE(1, all) in Shop(l) and 
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Fig. 4. The process for generating test sequences:we have developed a tool for the 
bounded area 



ASK_PRICE(2,all) in Shop(2)) are folded into ASK_PRICE(self, all) in Shop(X). 
The concrete states, Buying(l) and Buying (2), are folded into Buying (a: Y). As 
a result, the specification in Figure 3 can be simplified with the specification 
in Figure 2. From the simplicity of the description, we can conclude that our 
extended features make it efficient to describe an agent system. 

Furthermore, the parameterized description in the extended Statecharts cov- 
ers the diverse compositions of concrete agents. While we should set the number 
of concrete agents in conventional Statecharts, the parameterized specification is 
irrelevant to the number of concrete agents. The concrete agents can be flexibly 
instantiated from the parameterized description. Therefore, the extended State- 
charts are suitable for describing the flexible behaviors caused by the autonomy 
of agents and the dynamic properties of an agent system. 

4 Test Sequence Generation 

Figure 4 summarizes our approach to generating test sequences from extended 
Statecharts. First, it obtains concrete transitions from a parameterized speci- 
fication. Second, it extracts possible macro steps (PMSs) to present affections 
of external events to a system and analyzes event dependency by comparing 
PMSs. Then, it derives a reduced reachability graph from which representative 
sequences are generated. Finally, it generates equivalent classes from represen- 
tative sequences separately. Each equivalent class is used as a test controller to 
control test execution of a program. Refer to [12] for details on how to generate 
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an equivalent class and how to control test execution. Accordingly, Sections 4.1 
through 4.3 describe the activities of the process in more detail. Section 4.4 gives 
a comparison of results obtained by applying both our approach and flattening 
methods to the marketplace system. 

4.1 Event Analysis 

Since our approach statically analyzes a specification described with extended 
Statecharts, we should set the ids of concrete agents for obtaining concrete tran- 
sitions from the specification. Here, we consider two buyers (X={1, 2}) and two 
shops ( Y= { 1 , 2}) in the specification of Figure 2. 

Then, we obtain concrete transitions, which consist of concrete events and 
concrete states, by interpreting the semantics of the extended features. First, 
the role-based components are unfolded with concrete agents such as Buyer ( 1 ), 
Buyer (2), Shop(l) and Shop(2). Second, concrete events in each concrete agent 
are acquired by setting self to its id and instantiating the variable for agent id 
exhaustively. Finally, each state with the agent memory is unfolded with the 
relevant instantiations of an agent. For example, the following transitions are 
concrete transitions in Buyer(l) to be obtained from transitions in Buyer(X). 

— Buyer(l): Transitions = ( source state, event, target state, {internal events}) 

• ( Ready, ASKJPRICE(l,all), Waiting, {ask_price(l,all)} ) 

• ( Waiting, replay (all,l), Waiting, { } ) 

• ( Waiting, BUY(1,1), Buying(l), {buy jtem(l,l), leave(l,2)} ) 

• ( Waiting, BUY(1,2), Buying(2), {buy Jtem(l,2), leave(l,l)} ) 

The set of the above concrete transitions is equal to the set of transitions in 
Shop( 1) of Figure 3. In this way, we can obtain all concrete transitions from the 
specification described with extended Statecharts. 



4.2 PMS Extraction and Event Dependency 

For presenting how each external event affects a system, we define a possible 
macro step (PMS) as a global transition between configurations affected by not 
only a given external event but also the internal events caused by the external 
event. Therefore, we introduce the don’t care state to denoted as in config- 
urations. The don’t care states indicate agents unaffected by an external event 
and they can be replaced by any specific states in the agents. 

The process of extracting PMSs from concrete transitions finds a global tran- 
sition for only an external event and then refines the configurations of the global 
transition with the internal events. The refinement uses the following two rules. 

— if transitions for internal events exist in different concrete agents, they refine 
configurations together and one resultant PMS is extracted. 

— if transitions for internal events exist in the same concurrent agent, they 
refine configurations separately and several resultant PMSs are extracted. 
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(A) Possible Macro Steps (B) Dependency Table 



Fig. 5. For external events of the marketplace, (A) PMSs and (B) event dependency 



The first rule indicates that an external event affects several agents simulta- 
neously. The second rule indicates that an external event affects only an agent 
but the agent shows different behaviors according to its current state. A PMS 
for an external event is extracted by applying the composition of those rules to 
all internal events caused by the external event. 

In the marketplace example, the configuration consists of the states of four 
agents: [state of Buyer(l), state of Buyer(2 ), state of Shop(l), state of Shop(2)}. 
Figure 5(A) shows all PMSs extracted from the marketplace system: each state 
name is abbreviated to its head character. To clarify the process of extractions, 
let’s consider the event ASK_PRICE(l,all). Due to its direct effect, the source 
and target configurations of its PMS become [R, *,*,*] and [W, *,*,*] respectively. 
But the event also invokes askjprice(l,all) and both Shop(l) and Shop (2) react 
to ask-price (l,all). The event simultaneously changes the configurations from 
[*,*,W,W] to [*,*,R(1),R(1)]. In result, the overall source and target configura- 
tions of the PMS are refined to be [R,*,W,W] and [W,*,R(1),R(1)]. From the 
PMS, we know that ASK_PRICE(a,all) does not affect Buyer(2). 

Next, we generate a dependency table that presents the event dependency 
detected by comparing PMSs. In a concurrent program, the event dependency 
is formally defined as follows [13]: 

— Let E be a set of events and D C E x E be a binary, reflexive and symmetric 
relation. Then, D is a dependency relation iff all pairs of independent events 
((ei, e?) £ D) satisfy the following properties for all global states s £ S. 

el 

• if ei is executable in s and (s — ► s'), then e^ is executable in s if and 
only if e 2 is executable in s'. 

• if e\ and e-i are executable in s, there is a unique state s" such that 
s ^ s" and s s": wl = (ei, e-i) and w2 = (e 2 , ei). 

In this definition, (s -A s') denotes that the global state changes from s to s' 
by executing an event e, and (s =>■ s") denotes that the global state changes 
by executing a sequence w = (ei, e%, e*). By the definition, the order of inde- 
pendent events does not affect the global states reached by executions, so two 
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sequences obtained from each other by permuting adjacent independent events 
are equivalent. However, it is impractical to directly check the event dependency 
by using the definition, since it only describes the properties of dependent events. 
In order to directly obtain event dependency from PMSs, we newly introduce 
checkable syntactic conditions for event dependency. 

— Let E be a set of events and D C E x E be a binary, reflexive, and symmet- 
ric relation. D is a dependency relation iff all pairs of independent events 
((ei, e-i) (f D ) satisfy one of following conditions for all agents. 

• either ei or e 2 has a don’t care state for an agent, that is, ei and e 2 do 
not affect the same agent. 

• the state in an agent is the same state if both ei and ei affect the agent. 

These syntactic conditions do not contradict the properties of the previous 
definition. We show this with simple examples. The two PMSs ( [SI, S3], ei, 
[S2,S3] ) and ( [*,S3], e 2 , [*,S3] ) satisfy both conditions. In [SI, S3], both ei and e 2 
are executable. Also, ei is executable in [SI, S3] after executing e 2 and vice-versa. 
After executing both events, the configurations become [S2,S3]. Therefore, ei 
and e 2 satisfy the properties in the previous definition. However, if the event 
pairs do not satisfy the syntactic conditions they cannot satisfy the properties 
in the previous definition. Therefore, we can directly find the event dependency 
by comparing their configurations. 

Figure 5(B) shows the dependency table generated by comparing all pairs of 
events: pi is a PMS in Figure 5(A), ’0’ and T’ respectively denotes the indepen- 
dency and the interdependency. For example, p\\BUY (1 ,1) and p±:BUY(2,l ) are 
independent because they satisfy the first condition for Buyer (1) and Buyer (2) 
and the second condition for Shop(l) and Shop(2). 

4.3 Reduced Reachability Analysis 

The reduced reachability analysis constructs a reduced reachability graph with 
PMSs using event dependency and generates representative sequences of equiva- 
lent classes. This reduced reachability analysis is a form of partial order methods. 
The partial order method is one of the verification approaches used to alleviate 
the state-explosion problem. Its basic idea is that exploring all interleavings is 
not necessary for verifying some properties because the orders of independent 
events are irrelevant to the results or the state that is reached [13]. 

A reachability graph presents all possible changes of configurations by exter- 
nal events, and a reduced reachability graph is a subgraph of such a reachability 
graph. The reduced reachability graph does not present the changes of configu- 
rations by interleavings except for only one interleaving for independent events. 
For example, let ei and e 2 be independent events, that is, (so si — > S 3 ) and 
(so — > s 2 — > S3). While a reachability graph shows both changes, a reduced 
reachability graph shows either change, and so either si or S 2 is removed. 

Therefore, the reduced reachability graph is constructed by presenting prece- 
dences of dependent events and only an interleaving of independent events. If ei 
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Fig. 6. A reduced reachability graph for the marketplace system 



and e2 are independent, the graph presents only ei from so to si and then 
presents e2 from si to S3. If ei and e2 are interdependent, their orders are prece- 
dences of them and so the graph presents both events from so- From an initial 
configuration, the algorithm of graph construction is organized as follows: 

1 For each configuration s, 

1.1 Take an enabled PMS p whose source configuration includes s. P = {p}. 

1.2 For all PMSs p in P , 

A if p is enabled in s, add all PMSs p' to P such that p' and p are 
interdependent and their source configuration can be intersected. 

B if p is disabled in s, add all PMSs p" to P such that p" and p are 
interdependent and that the target configuration oip" and the source 
configuration of p can be intersected. 

1.3 Repeat step 1.2 until no more PMSs can be added. Then present all 
enabled PMSs in P to s in the graph. 

2 Repeat the above process for new configurations. 

This algorithm is the adapted version of the partial order method in [13] for 
PMSs. The changed parts are step A and step B that respectively correspond to 
”in conflict” and ’’preceding” in the partial order method. 

By applying the algorithm to the PMSs of Figure 5(A), the reduced reach- 
ability graph of the marketplace system is constructed as shown in Figure 6; it 
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Fig. 7. A snapshot of representative sequences generated from the marketplace system 



omits the behaviors to start with ASK_PRICE(2, all). In the graph, we restrict 
each path does not contain any external event twice and we also note that con- 
figurations including the same states are distinguished from each other by a set 
of events that are executed for reaching the configuration. 

In the graph, the configuration [W,W,W,W] shows good examples for the algo- 
rithm. Four events, BUY(1,1), BUY(1,2), BUY(2,1) and BUY(2,2), are enabled 
in the configuration, and BUY(2,2) and BUY(2,1) are independent of BUY(1,1) 
and BUY(1,2). Therefore, the algorithm adds BUY(1,1) and BUY(1,2) to the 
configuration and BUY (2,1) and BUY (2,2) are added in each following config- 
uration. As a result, the sub-sequence {BUY (1,1), BUY(2,2 )) represents two 
equivalent sequences {BUY(1,1), BUY (2,2)) and {BUY (2,2), BUY (1,1)). 

4.4 Comparison of Testing Agent Systems 

In contrast to flattening methods which uses a complete reachability graph, our 
approach uses a reduced reachability graph. While the complete graph for the 
same part shown in Figure 6 includes 27 nodes and 38 edges, the reduced graph 
contains 21 nodes and 24 edges. Furthermore, our approach obtains 8 represen- 
tative sequences of equivalent classes from the reduced graph, out of 48 possible 
sequences. For the entire marketplace system, 16 representative sequences in 
Figure 7 are generated while there are 96 possible sequences. 

Furthermore, the number of test sequences affects costs and efforts in test ex- 
ecution. To verify the behaviors of equivalent classes, flattening methods require 
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Table 1 . Number of equivalent sequences in equivalent classes to test sequences: test 
sequences are numbered from the leftmost sequence in Figure 7 



Test Sequences 


Number of Sequences in An Equivalent Class 


TSi 


4 Equivalent Sequences 


ts 2 


4 Equivalent Sequences 


ts 3 


4 Equivalent Sequences 


TSa 


4 Equivalent Sequences 


TS 5 


8 Equivalent Sequences 


ts 6 


8 Equivalent Sequences 


TS r 


8 Equivalent Sequences 


TS s 


8 Equivalent Sequences 



48 test executions in the worst case, because they do not consider equivalence 
relations among test sequences. However, our approach requires only 8 test ex- 
ecutions with representative sequences of equivalent classes. 

Although our approach generates a smaller number of test sequences than 
flattening methods, Equivalent classes can be separately generated from repre- 
sentative sequences and they cover all possible sequences [12]. Table 1 presents 
the number of equivalent sequences for each test sequence: test sequences are 
numbered from the leftmost sequence in Figure 7. For example, let’s consider 
TS 6 : ( ASK_PRICE(l,all ), REPLY (1,1), REPLY (2,1), ASK_PRICE(2,all), RE- 
PLY(1,2), REPLY(2,2), BUY(1,1), BUY (2,2]). This sequence has the following 
pairs of independent events: ( REPLY(1,1 ), REPLY(2,1 )), ( REPLY(1,2 ), RE- 
PLY(2,2)) and ( BUY(1,1 ), BUY(2,2)). By permuting these independent events, 
the test sequence has 8 equivalent sequences, including itself, in its equivalent 
class. In result, all of 48 possible sequences are divided into 8 equivalent classes, 
so our approach does not omit any sequence in testing the agent system. 



5 Conclusions and Future Works 

In this paper, we proposed an approach to specification-based testing of an 
agent system. First, we presented the modeling method for agent systems. For 
an elaborate description, we extended not sequence diagrams but Statecharts. 
The extended Statecharts introduce extended features for agent systems, such as 
role-based description, various event types and agent memory in states. Because 
the features consider the autonomy and dynamic properties of agent systems, our 
modeling approach is suitable for describing flexible behaviors of agent systems. 

Then, we proposed an approach to generating test sequences from the ex- 
tended Statecharts. Because of the autonomy and concurrency in agent systems, 
conventional analysis methods have limitations such as the large number of test 
sequences. However, our approach is based on the notion of the partial order 
method and it generates only representative sequences for equivalent classes. 
Thus, it efficiently manages possible sequences in a specification and overcomes 
high costs of not only test sequence generation but also test execution. 
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Our future work is to extend our analysis method to a dynamic version. 
In the current approach, we generate a given number of agents and analyze 
them statically. However, in actual agent systems, agents can be created and 
eliminated dynamically. Therefore, to test such systems we have to deal with 
this dynamic behavior effectively. One possible approach is to extend the partial 
order method so that it is applicable to an unbounded number of homogeneous 
agents. By developing such an extended method, we believe we can successfully 
obtain finitely represented control information for dynamic systems. 
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Abstract. We introduce a methodology to test autonomous agents de- 
scribed by means of utility state machines. In contrast with the classical 
approach for testing state machines, we will use other utility state ma- 
chines as test. In fact, the machine playing the role of the test will be 
in charge of guiding the IUT so that it performs the operations (i.e. ex- 
changes of resources) indicated by the specification. 



1 Introduction 

E-commerce technologies introduce several advantages in usual human economic 
interaction. For instance, they allow vendors to sell products without temporal 
or storage restrictions and they provide customers with powerful mechanisms to 
compare prices. In particular, autonomous commerce agents are one of the most 
interesting and challenging technologies in e-commerce (see e.g. [3, 4, 14, 8, 5]). 
They are autonomous entities that perform, on behalf of their respective users, 
some of the activities required in economic processes. For instance, autonomous 
commerce agents may search for interesting products, advise their users about 
interesting offers, negotiate with other agents, or even perform transactions au- 
tonomously. Besides, e-commerce platforms and multi-agent e-commerce sys- 
tems use to be heterogeneous distributed systems where different components 
perform complex interactions. Actually, guaranteeing a correct behavior is spe- 
cially hard in this kind of systems. However, reliability is a must for the success 
of e-commerce systems: Since they directly affect the patrimony of the users, 
their social implantation dramatically depends on whether users can trust them. 

Taking as objective the validation of e-commerce systems, several works 
have been proposed to study the correctness of commerce communication proto- 
cols [10, 1]. Communication protocols are a key aspect in the validation of any 
e-commerce system, since any economic environment takes as first premise that 
any message sent by an economic party arrives correctly at the receiver. Only 
in this case commercial negotiation can be successfully performed. However, let 
us note that techniques for validating commerce communication protocols are 
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not different to those used to check any kind of communication protocol, as they 
mainly focus on analyzing low-level details that are common to any distributed 
system. Nevertheless, e-commerce systems have enough intrinsic peculiarities to 
suggest the development of new specific validation techniques for this domain. 
Let us note that e-commerce systems are economic environments where entities 
compete for resources. Hence, a suitable conceptualization of the high-level de- 
tails of such systems consists in representing and studying the economic behavior 
of the entities appearing in them. 

In this paper we will provide a testing methodology to validate the high-level 
behavior of autonomous commerce agents in e-commerce systems. The aim of 
the testing mechanism will be to check whether the economic behavior of an 
implemented agent conforms to its corresponding specification. The high-level 
specification of an agent, concerning its economic behavior, can be defined as 
“get what the user said he wants and when he wants it”. We will consider that 
the specific preferences of the users will conform a specification. Therefore, we 
will need a proper formalism to represent this kind of specifications, that we will 
call utility state machines (see [12, 13]). 

In our testing methodology we will stimulate the implementation under test 
(that is, the IUT is the implementation of an agent) according to a given test 
case/suite. Since we are interested in high-level behavior, it would not be co- 
herent to stimulate the IUT by sending a sequence of actions that conforms 
to a given communication protocol. Thus, in contrast with usual testing ap- 
proaches, the part of the behavior to be tested will not be which actions the 
agent performs but the result of these actions, that is, whether the results of the 
actions conform to the specific user expectations. In other words, we will test 
whether the tested agent is able to gain some profit according to the user pref- 
erences. So, our primary goal is not to test whether an agent behaves according 
to a given communication protocol since, as we said before, there already exist 
other formalisms to perform this task. On the contrary, as we are interested in 
abstracting low-level issues, the only suitable way to perform the stimulus will 
be by giving the tests the form of another autonomous commerce agent, so that 
they interact with the IUT in the same way as a real system would do. 

In terms of related work there are innumerable papers on e-commerce in 
general or on topics as e-commerce systems/ architectures and agent-mediated e- 
commerce. This number strongly decreases when considering formal approaches. 
In this case we may mention [6, 7] where, taking as basis the language PAMR [9], 
process algebras to specify e-barter systems were introduced. Regarding testing 
and validation techniques for e-commerce we may mention [11, 2] where specific 
case studies are considered. In fact, as far as we know, our paper represents the 
first generic framework to formally specify and test e-commerce systems. 

The rest of the paper is structured as follows. In Section 2 we briefly review 
the formalism that allows us to specify autonomous commerce agents. In Sec- 
tion 3 we present our testing methodology. The main highlight of this approach 
is that in order to test the behavior of an agent we use a suitable agent as test. 
Finally, in Section 4 we present our conclusions and some lines for future work. 
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2 Utility State Machines 

In this section we briefly review the notion of utility state machine. A more 
detailed presentation of this formalism can be found in the companion paper [13]. 
We use these machines to describe agents representing users. The preferences of 
the user in a given moment will be given by its utility function. Utility functions 
associate a value (a utility measure) with each possible combination of resources 
a user could own. 

Definition 1. We consider M+ = {a; £ M \ x > 0}. We will usually denote 
vectors in R n (for n >2) by x,y, .. . We consider that 0 denotes the tuple having 
all the components equal to zero. Given x £ M n , Xi denotes its i-th component. 
We extend some usual arithmetic operations to vectors. Let x,y £ M m . We 
define x + y = (x\ + yi, . . . , x n + y n ) and x ■ y = {x\ ■ yi, . . . , x n ■ y n ). We write 
x < y if for any 1 < i < n we have Xi < yi- 

Let us suppose that there exist n different kinds of resources. A utility function 
is any function f : R" — » R + . □ 

In order to specify agents we use utility state machines [12, 13]. This formal- 
ism is indeed an adaption and extension to our purposes of the classical notion of 
extended finite state machines (EFSM). In particular, we have to take into account 
time as a factor that influences the preferences of users. Besides, time will affect 
agents in the sense that any negative transaction will imply a deadline for the 
agent to retrieve the benefits of it. In addition, time will appear as part of the 
freedom that specifications give to implementations: It does not matter whether 
an agent immediately performs a transaction as long as its decision is useful to 
improve the utility in the long term. 

Definition 2. We say that the tuple M = (S, Si n ,V,U,at,mi,T) is a utility 
state machine, in short USM, where we consider that 

— S is a set of states. 

— Si n £ S is the initial state of M. 

— V = (t,x i, ... ,x n ) is a tuple of variables, where t represents the time elapsed 
since the machine entered the current state and x±, ... ,x n represent the re- 
sources that are available to be traded in the e-commerce environment. 

— U : S — > (R" +1 — » R+) is a function associating a utility function with 
each state in M . 

— at is the amortization time. It denotes the maximal time M may stay without 
retrieving the profit of the negative transactions that were performed in the 
past. 

— mi is the maximal investment. It denotes the maximal amount of negative 
profit the machine should afford. 

— T is the set of transitions. Each transition is a tuple (s, Q, Z, s 1 ), where 
s,s' £ S are the initial and final state of the transition, Q : K" +1 — * Bool 
is a predicate on the set of variables, and Z : R™ — > Kf is a transfor- 
mation over the current variables. We require that for any state s there 
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do not exist two different transitions t\,t 2 £ T, with t\ = s'f) 

and t 2 = (s, Q 2 , Z 2 , S 2 ), and a tuple r such that both Qi(r) and Q 2 (r) hold. 

□ 



It is worth to point out that the set of transitions T does not include the com- 
plete set of transitions the specification will allow real agents to perform. Some 
additional transitions must be considered: transactions and passing of time. The 
former will be used to denote the transactions agents will be allowed to perform. 
Given a USM M , both transaction and time consumption transitions may be im- 
plicitly inferred from the definition of M . We will give the formal representation 
in the forthcoming Definition 5. Next we introduce the notion of configuration , 
that is, the data denoting the current situation of a USM. A configuration con- 
sists of the current state, the current values of the variables, and the pending 
accounting of the machine. 

Definition 3. Let M = (S, Si n ,V,U, at,mi,T) be a USM. A configuration of M 
is a tuple ( s,r,l ) where 

— s £ S is the current state in M , 

— r = (u, ri, . . . , r n ) £ J?" +1 is the current value of V, and 

— I = [(pi, ei), . . . , (p m , e m )] is a list of pairs (profit, time) representing the list 

of pending accounts. □ 



For each pair (p, e) £ l we have that p represents a (positive or negative) 
profit and e represents the expiration date of p, that is, the time in which a profit 
greater than or equal to — p must be retrieved, if p is negative, or the time in 
which p will be considered a clear profit if no negative profit is registered before. 

Next we present some auxiliary definitions. Intuitive explanations of these 
notions can be found in [13]. 



Definition 4. Let M = (S, Si n ,V,U, at,mi,T) be a USM and c = (s,r,l) be 
a configuration of M, with r = (u, rq, . . . , r n ) and l = [(pi, ei), . . . , (p m , e m )]. 
The maximal waiting time for M in the configuration c, denoted by 
MaxWait(M,c), is defined as min{ei, mini?/ | 3(s, Q, Z, s") £ T : u' > u A 
Q{u',n,...,r n )}} 

If ei is actually the minimal value and pi > 0 then we say that M per- 
forms a clear profit, which is indicated by setting true the auxiliary condition 
ClearProfit(M,c). On the contrary, if e\ is the minimal value and p\ < 0 then 
we say that M fails its economic objective, which is indicated by setting true the 
auxiliary condition TargetFailed(M,c). 

The update of the list of pending accounts l with the new profit a, denoted by 
Update(l,a), is defined as: 



' [(a, at + it)] 
l H h[(u, at T u)] 
(pi + a,ei) : l' 
Update(l' ,pi + a) 



if l=[] 

if /=(p 1 ,e 1 ):/ / A ^>0 
if Z=(p 1 ,e 1 ):/ / A^<OA^>0 
if Z=(p 1 ,e 1 ):/ / A^<OA^<0 



Updatefl , a) = < 
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Finally, the accumulated profit of a list of pending accounts l, denoted by 
Accumulated)!) , is defined as 

Accumulated)!] = \^ , . , , ,, 

^ ' \p + Accumulated)! ) if l=(p,e):l G 

Let us note that profits in any (non-empty) list of pending accounts are either 
all positive or all negative. We have used a functional programming notation to 
define lists: [ ] denotes an empty list, l ++1' denotes the concatenation of the 
lists l and l', and x : l denotes the inclusion, as first element, of x into the list l. 

Given a USM M, an evolution of M represents a configuration that the USM can 
take from a previous configuration. We will consider four types of evolutions: 
changing the state, passing of time, passing of time with failure, and performing 
a transaction. 



Definition 5. Let M = ( S,Si n ,V,U,at,mi,T ) be a USM and c = ( s,r,l ) be 
a configuration of M , with r = (u, rq , . . . , r n ) and l = [(pi, ei), . . . , ( p m , e m )]. An 
evolution of M from c is a tuple (c, c' , tc)x where F = (s', r', l') , K £ {a, f3, /3' , 7 } 
and tc £ M+ are defined according to the following options: 

(1) (Changing the state) If there exists (s,Q, Z, s") € T such that Q(r) holds 
then K = a, tc = 0, s' = s" , and r' = (0, r), . . . , r' n ), where (r^, . . . , r ' n ) = 
Z(ri , . . . ,r„) and l ' = [(pi,ei -u),..., (pm,e m ~ «)]■ 

(2) (Passing of time) If the condition of (1) does not hold then for any tr € K+ 
such that 0 < tr < MaxWait(AI, c) — u, we have tc = tr, s' = s, r' = 
(u + tr,r 1 , . . . , r n ), and V is defined as follows: 



l’ = 



[{Pi, 62 ), • ■ • j (jpmi e TO )] if ClearProfit{M,c) V TargetFailedfAI,c) 
l otherwise 



In addition, K = (3 ' if TargetFailed(M, c) and K = (3 otherwise. 

(3) (Transaction) 

If the condition of (1) does not hold then for any r" = ( u,r'{ , . . . ,r") > 0 
such that U(s)(r") — U(s)(r) + Accumulated)!) > -mi, we have K = 7 , 
tc = 0, s' = s, r' = r" , and V = Update(l, U(s)(r') — U(s)(r)). 

We denote by Evolutions(M, c) the set of evolutions of M from c. 

A trace of M from c is a list of evolutions l with either l = [ ] or l = e : l' , 
where e = {c,c',v) K £ Evolutions(M, c) and l' is a trace of M from c' . We 
denote by Traces(M,c) the set of traces of M from c. □ 

First, if one of the guards associated with a transition between states holds 
then the state changes, the time counter of the state is reset to 0 and the expira- 
tion dates of the pending accounts are shifted to fit the new counter. The second 
clause reflects the situation where the machine let the time pass an amount of 
time less than or equal to the maximal waiting time. Besides, if the elapsed time 
corresponds to the one when a positive or negative previous profit expires, then 
either this profit is considered clear or a failure is produced, respectively, being 
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such profit eliminated from the list. Finally, if a machine performs a transaction 
then we require that it does not give resources that it does not own and that 
the accumulated losses stay below the maximal threshold. Let us note that the 
second and third types of transition can be performed only if the corresponding 
USM cannot change its state. 

In the next definition we identify the traces that are free of failures. 

Definition 6 . Let M be a USM and c be a configuration of M . Let us sup- 
pose ci = c and let a = [(c 1 ,c 2 ,ti)ic 1 , . . . , (c n _i, c n , t n _i).R: n _i] € Traces{M , c) 
be a trace of M from c. We say that a is a valid trace of M from c if there does 
not exist 1 < i < n— 1 such that Ki = ft' . We define the set of valid traces of M 
from c by ValidTraces{M,c). □ 

Next we extend the previous framework so that systems, made of USMs in- 
teracting among them, can be defined. Intuitively, systems will be defined just 
as tuples of USMs, while the configuration of a system will be given by the tuple 
of configurations of each USM. 

Definition 7. Let have Mi = {Si, Si n i,V,Ui, afi, mii, Tf). We say that the tuple 
S = (Mi, . . . , M m ) is a system of USMs. For any 1 < i < m, let Ci be the 
configuration of Mi. We say that c = (ci, . . . ,c m ) is the configuration of S. □ 

The transitions of a system will not be the simple addition of the transitions 
of each USM within the system, as some of the actions a USM can perform will 
require synchronization with those performed by other USMs. This will be the 
case of passing of time and transactions. In fact, the only actions that do not 
require a synchronization are the ones associated with changing the state of 
a USM. In contrast with transactions and passing of time, changing the state is 
not a voluntary action. In other words, if the condition for a USM to change its 
state holds then that USM must change its state. In the meanwhile, transactions 
and passing of time transitions will be forbidden. 

In the following definition we identify the set of evolutions a system can 
perform from a given configuration. In order to make explicit the failure of 
any of the USMs in the system, we distinguish again passing of time transitions 
producing a failure. In this case, we will explicitly indicate the set of USMs 
producing a failure. Hence, the label (3a denotes a passing of time transition in 
which the USMs included in A produced a failure. So, a failures-free passing of 
time transition is denoted by /3g. 

Definition 8 . Let S = (Mi, . . . , M m ) be a system and c= (ci, . . . , c m ) be a con- 
figuration such that we have Mi = {Si, Si n ,, V, Ui, ati,mii, Tf) and = {si,ri, If) 
for any 1 < i < m. An evolution of S from c is a tuple {c,c',tc)K where 
c’ = {d 1 ,...,d m ), with di = {sfrfl’f), K <E { 0 , 7 } U {fi A \ A C {1 ,...,m}}, 
and tc £ R+ are defined according to the following options: 

(1) (Changing the state) If there exists (ci,d(, 0) a € Evolutions{Mi,Ci) then 

K = a, tc = 0, and for any 1 < j < m we have c = Cj if i ^ j, while 
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(2) (Passing of time) If the condition of ( 1) does not hold and there exits tr such 
that for any 1 < i < m there exists ( Ci,c'(,tr)$ € Evolutions(Mi,Ci) with 
S G {/3, P'}, then tc = tr, c' = c" for any 1 < i < m, and K = Pa where the 
set A is defined as A = {i \ (ci,c'( ,tr)p> € Evolutions(Mi,Ci)}. 

(3) (Transaction) If the condition of (1) does not hold and there exist two in- 
dexes j and k, with j ^ k, such that for l € {j,k} we have (c;,c",0) 7 G 
Evolutions(Mi, ci) and c" = (s", r", l'(), with rj+fk = r" + r'f, then K = 7, 
tc = 0, c'- = c", c' k = c", and for any 1 < i < m, with i ^ j,k, we have 

4 = Ci. 

We denote by Evolutions(S, c) the set of evolutions of S from c. 

A trace of S from c is a list of evolutions l where either l = [ ] or l = e : V , 
being e = (c,c',v)k G Evolutions(S,c) and V a trace of S from d . We denote 
by Traces(S , c) the set of traces of S from c . □ 

If a USM can change its state then the corresponding transition is performed 
while any other USM remains unmodified (first clause). If no USM can modify its 
state then passing of time and transaction transitions are enabled. In the first 
case, the system can let the time pass provided that all the USMs belonging to the 
system can. In the second case we require that trading USMs can (individually) 
perform the exchange and that goods are not created/destroyed as a result of 
the exchange. Let us note that only bilateral transactions are considered since 
any multilateral exchange can be expressed by means of the concatenation of 
some bilateral transactions. 

Similarly to the reasoning that we did for single agents, we can identify the 
valid traces of systems. In this case, we are interested in identifying the traces 
such that a specific USM belonging to the system produces no failure. 

Definition 9. Let S = (Mi, . . . , M m ) be a system and c be a configuration of S. 
Let us suppose c\ = c and let a = [(ci, C2, ti)^, > • • , (c n -i, c n , t n -i)K n -!] G 
Traces(S , c) be a trace of S from c. a is a valid trace of S from c for the USM Mi 
if there does not exist 1 < j < n — 1 such that Kj = Pa with i G A. We denote 
the set of valid traces of S from c for Mi by ValidTraces(S, c, Mf). □ 

3 Testing Autonomous Commerce Agents 

In this section we describe how to interact with an IUT so that the observed 
behavior is as helpful as possible to infer conclusions about its validity with 
respect to a specification. We will create artificial environments to stimulate the 
IUT according to a foreseen plan. These environments will be the tests in our 
testing process. As we said in the introduction, tests will be defined in the same 
way we define specifications. Thus, the definition of tests will focus only on the 
high-level economic behavior. Besides, the actions available for tests will be the 
same as those for specifications. Let us remark that if tests included low-level 
details that made explicit their way to interact with the implementation then 
the test would check details that the specification actually does not define. 
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As it is usually the case in formal approaches to testing, the design of tests 
will be guided by the specification. The main aim of a test will be to check 
whether the IUT exchanges items as the specification says. It is worth to point 
out that the behaviors of the specification producing a failure (that is, a /3' 
transition) will not be considered as valid in the implementation, since they 
should be avoided. Each test will focus on testing a given state (or set of states). 
So, the first objective of a test will be to conduct the IUT to the desired state 
of the specification. Then, the test will behave according to a given economic 
behavior. Thus, we will check whether the joint evolution of the test and the 
IUT conforms to the (failure free) behavior we would have in the specification 
of a system containing both agents. 

Conducting the IUT to a desired state consists in taking it through states 
equivalent to those of the specification until that state is reached. In other words, 
the test has to induce the IUT to fulfill the guards governing the transitions 
between states. The test will be able to do so by exchanging resources with the 
IUT so that the guards are fulfilled. In order to perform this task, the utility 
functions of the test must be designed so that they favor the correct flow of 
resources, that is, the test must get happier by giving resources to the IUT in 
such a way that the IUT fulfills its guards. Nevertheless, endowing the test with 
the suitable utility functions is not enough to guarantee that the test and the IUT 
will always evolve together until the corresponding guards are fulfilled. This is so 
because the specification leaves a free room for the IUT to non- deterministically 
perform transactions. Thus, the joint evolution of the IUT and the test could 
lead the IUT to own different baskets of resources to those expected. Since 
deviating from the foreseen path of the test is not incorrect in general, tests will 
be designed so that they provide diagnosis results even when the desired path is 
not followed by the IUT. 

In order to define a test, the first decision consists in fixing the set of states 
it will be intended to guide the IUT through. 

Definition 10. Let M = ( S , s,; n , V, U, at, mi, T) be a USM. A path of states in M 
is a list [si, . . . , s m \ where si = s„ and for each 1 < i < m - 1 t»e have that 
there exists (si,Q, Z, Si+ 1 ) £ T. □ 

The availability of a part of a path to be performed will be strongly in- 
fluenced by the exchanges performed in previous states of the path. The key 
to understand and predict the evolution of resources at a given state is that 
a USM is forced to perform exchanges so that, in the long term, utility never 
worsens. Therefore, if a guard between states is only fulfilled in configurations 
where the utility is less than the current utility then the USM will never be 
able to perform the corresponding transition. The following definition checks 
whether it will be possible for a USM to evolve across a given path. Prior to for- 
mally define this concept we introduce some auxiliary notation. We give a sim- 
ple notion to identify the list of states ranged in a trace as well as both the 
baskets of resources which made possible each transition and the baskets ob- 
tained after each transition. These baskets give us a possible way to deal with 
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resources so that the test can guide the IUT through the path. In the follow- 
ing definition we also introduce notation to access some elements within a list 
of tuples. Given a list l we have that l.i denotes a list formed by the i th ele- 
ment of each tuple appearing in /. Besides, Z, denotes the i th element of the list. 
For example, if we consider l = [(1, 2, 3), (3, 4, 1), (5, 2, 7), (8, 1, 6), (6, 5, 4)] then 
1.2 = [2,4, 2,1,5] and Z3 = (5,2,7). Moreover, we can combine both functions. 
For instance, (Z. 2)4 = 1. 



Definition 11. Let Al be a USM, c be a configuration of Al , and a£ Traces(M, c) 
be a trace of Al from c. The list of state transitions through a, denoted by 
StateTran(a) , is defined as 



StateTran(a) 



[} 

( s,r,r ') : StateTraufa 1 ) 
StateTran{<r') 



if a = [ ] 

if a = 0) a : a’ 

if a = ex ■ o’ A K ^ a 



where r = (ri, . . . , r n ) and r' = (r^, . . . , r' n ), with v = (t, r±, . . . , r n ) and v' = 
r' n ). 

Let l be a list of n-tuples. For any i £ N, with i > 1, such that l has at least i 
elements we denote by It the i-th element of l. For any 1 < i < n we define the 
list l.i as 

= ** = [] 

L x i ; W-i) if l = (xi, ...,Xi,...,x n ) :l' 

We say that the path rj = [si, . . . , s m \ in Al is possible from c if there exists 
a trace a = [(ci, C2, ti)^ , • • • , (c„_i, c n , t„_i)ic Tl _ 1 ] € ValidTraces{Al 1 c) such 
that p = StateTran(a).l + + [st„], where c n = (st n ,rf[,l n ). In this case we say 
that StateTran(a).2 is a possible use of resources to perform p and that a is 
a possible trace to perform p. □ 

Once we have identified a possible use of resources to perform a given path, 
we can define a test that gives to the IUT the resources it needs to perform 
the next transition of the path at every state. Basically, the test will be initially 
provided with the resources needed to lead the IUT to the final state. These can 
be computed by using the notion of possible use of resources introduced in the 
previous definition. Besides, the test will be built in such a way that each state 
in the path will have a respective state in the test. In each of these states, the 
utility function of the test will induce that the test does not care about giving 
to the IUT as much resources as it needs so that it may pass to the next state. 
In order to do so, the utility function of the test will return the same utility 
regardless of the amount of items it owns, provided that it keeps the needed 
reserve of resources. This reserve of resources consists of the resources the test 
will give to the IUT in future states to continue guiding it towards the final state 
of the path. The only exception will be the case when some of the resources of 
the IUT must be removed in order to fulfill the transition guard. In order to 
steal the appropriate resources from the IUT, so that it fulfills the guard, the 
test will reward these items with its utility function. In the following definition 
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we describe how to create the utility function of the test so that it promotes 
an exchange between the resources the test wants to remove from the IUT and 
those it wants to give to it. In this case, v plays the role of the former and w 
plays the role of the latter. Let us note that each kind of resources will have to 
be either given or removed, but not both. 

Definition 12. Let v, w G JFI+ such that v * w =i 0. Let P,Q G 1R+ be such that 
p > g. If v 0 then the function denoting preference of v over w, denoted by 
is defined, for any x G IRff, as 

^v,w(x) = p ■ <L> &( x i> Vi), | {Vi | Vi > 0} | ) + 

Q-® (El <i< n &( X i’ W i)’ I i W i I W i > 0} | ) 

where b) is equal to % if b ^ 0 and equal to 0 if b = 0. Ifv = 0 we simply 
consider that &v,w{ x ) = 0. □ 

Lemma 1. Letv,w G K" such thatv ^ 0 andv-w = 0. We have that [ l / v,w(v) > 
&v,w{w)- 

Proof. Let us compute First, we have Ei<i< ra ${ v i, v i) = I { v i \ v i > 0} | . 

This is so because the addition in the left hand side adds 1 for each Vi > 0. 
Hence, ^{J2i<i< n ^( v ^ v i), \ {vi \ Vi > 0} | ) = 1, and so we have that the first 
additive factor in the expression >,w(v) is p. Besides, since for any 1 < * < n it 
holds Vi = 0 or Wi = 0, we have that <P(vi,Wi) = 0, for any 1 < i < n. Thus, it 
is fulfilled = Then, the second additive factor in expression 

{ t r v,w(v) is 0, so we obtain x I / v.w(v) = P- By using similar arguments we obtain 
'P v,w(w) = g and since p > g we conclude { I / v,w(v) > &v,w(u>). □ 

Let us remark that by using the function Py.w as a component of the test we 
will favor that the test and the IUT exchange resources so that the appropriate 
transition guards of the IUT hold. This is so because both agents will get happier 
by exchanging the exact resources we want them to exchange. In particular, if 
\Lv,w is adequately inserted in the test so that v represents the resources the 
test must take from the IUT and w represents those it will give to the IUT, 
then the exchange we want to perform would improve the utility of the test, 
since its utility function will return a higher value with v than with W. Besides, 
if the exchange of v by w is represented in a possible use of resources of the 
specification then the specification will fulfill its guard to change its state by 
performing that exchange. Since a possible use of resources takes into account 
only those exchanges where the USM does not lose utility, the utility function of 
the specification will accept such a exchange. Similarly, any IUT conforming to 
the specification will do so. 

We are now ready to define the test that will lead the IUT through a given 
path. As we said before, each state in the test will represent the corresponding 
state of the specification in the path. Besides, in order to properly track the IUT, 
we need the test to change its state exactly when the specification is supposed to 
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do it. Therefore, the guards of the transitions of the tests will hold exactly when 
the corresponding guard of the specification does. As we know the total amount 
of resources in the system, the test can trivially compute the resources the IUT 
has by subtracting its own resources from the total amount and accounting the 
resources introduced or removed from the market in previous transitions. Thus, 
the guards of the test can be easily defined in terms of its own resources. The next 
definition provides a mechanism for creating a test to guide the IUT through 
a given path. In this definition, U and r denote, respectively, the utility function 
and the resources the test will apply in its last state. 

Definition 13. Let M = ( S , V, U, at, mi, T) be a USM and let c= ( Sm, U [ ]) 
be a configuration of M . Let p = [si, . . . , s m ] be a possible path of M from c and 
let a £ ValidTraces{M, c) be such that a is a possible trace to perform p. A test- 
leading M through p and applying U and f is a USMT = (S' , s' in , V, U' , at, mi, T') 
where 



— S' = {sj_ , . . . , s' m }, where s[, ... ,s' m are fresh states. 

S in A ' ^ 

— U'(s' m ) = U and for any 1 < i < m — 1 we have 



U'(s'i)(t,x) 

where 



$ Steal, ,Givei( x ~ Reserve f) if x > Reserve , 

0 otherwise 



Reserve j = r + ft{{StateTran{<j) .2) j — (StateTran( (t).3)j_i) 

Steali = L2((StateTran(a).3)i-i — ( StateTran(a).2)i ) 

Give-i = Q{{StateTran{a).2)i — ( StateTran(cr).3)i-i ) 



where ft returns the original tuple but substituting negative numbers by 0 
and we assume that (StateTran(a).3)o = rm- 
— T = {(si, Q[,id, s' 2 ), ■ ■ ■ , (s' m _ 1 , Q' m _ 1 , id, s' m )} is such that for any 1 <i< 
m we have Q'i{t,r) = Qiit, (ri^+Reserveo—r)), where id is the identity func- 
tion, Qi is such that (s*, Qi, Zi, Sj+i) € T and Qi{t' ,(StateTrav{a).2)i) = 
True for some t! and Zi, with Zi((StateTran(a).2)i) = ( StateTran(a).3)i , 
and Modifi = ( StateTran(o').3)j — ( St at eTran(a) .2) j 

The initial configuration of T is given by c' = (. s' in , (0, Reserve 0 ), [ ]). □ 

Let us comment the previous definition. Every state in the path p has a cor- 
responding state in the test. Let us remark that if 77 contains cycles then each 
occurrence of the same state in 77 will be represented by a different state in the 
test. The utility function of each state in the test will promote that the resources 
the test wants to give to the IUT (that is, Give,) are less valued than those it 
wants to take from the IUT (that is, Steal,). Since, by construction, the prefer- 
ences reflected in the specification are opposite to those of the test, the exchange 
will be possible if the IUT conforms to the specification. Besides, the utility func- 
tion of the test will take care of keeping the needed resources for future states 
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in the path (given by Reserve,;). This is done by setting the utility to null if 
these resources are not owned. The values of Give^, Steals, and Reserve^ are 
calculated by analyzing er, that is the possible trace we choose to execute the 
path 77. By comparing the available resources when arriving at the current state 
and when leaving it (denoted by (StateTran(cr).3)i_i and (StateTran(er).2)i, 
respectively), we calculate the resources the IUT must get/lose in each state to 
advance along the path 77. The transitions of the tests will be activated exactly 
when the specification would do it. Thus, the guards of the test {Q'f) are defined 
in terms of the guards of the specification ( Qi ). Let us remark that the expres- 
sion Tin + Reserveo + Modif, — r allows the test to determine the resources the 
specification owns, assuming that the test owns the basket r. The reason is that 

+ Reserveo is equal to the total amount of resources existing initially in the 
system, while Modif , denotes the subsequent variation of this amount due to the 
resources introduced/removed by the specification in the next transitions by its 
functions Z{. The value Modify is computed by comparing the tuples of resources 
before and after each modification of the state (denoted by (StateTran(cr).2)j 
and (StateTran(cr).3) ; /, respectively). Let us note that the test does not modify 
the total amount of resources since its functions of transformation of resources 
are always given by the identity function. 

Once a test is defined, we can apply it to the IUT to detect faults. We will 
be able to detect faults by comparing the ideal observable behavior of a system 
consisting of the specification and the test with the real observable behavior of 
the real system consisting of both agents. In order to perform these observations 
we have to fix the kind of actions we will be able to observe. First of all, we 
will suppose that the initial amount of resources of the tested agent is known. 
Second, we will suppose that each agent in the system provides us a mechanism 
to observe its basket of resources at any time. This requirement will be basic to 
trace the economic behavior of the system. Let us note that if we can access the 
baskets of resources of the agents then we can detect the performed transactions 
just by checking whether the baskets change. 1 Besides, another event we can 
detect is the passing of time. Nevertheless, as we assume that the tested agents 
are black boxes, we will not be able to check whether an agent changes its state. 
Summarizing, the visible events will be the transactions of our agents and the 
elapsed time. The following definition formalizes the kind of traces we will be 
able to observe from a system of agents. 

Definition 14. An observable trace of a system is a list [ei,...,e m ] where 
for any 1 < i < m we have that either = (f, /?), with t £ H+, or e, = 
(x, (oi, 02), 7), with x£ K". □ 

In the previous definition (f , /?) represents the passing of t units of time while 
(x, (01,02), 7) represents a transaction between the agents M ai and M a2 . In this 
last case the difference between the new and the old baskets of resources is equal 



1 Alternatively, we could suppose that the performed transactions are the only infor- 
mation we can observe. In this case it is also trivial to infer the baskets of resources 
of the agents at any time. 
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to x in the case of the agent M ai and equal to —x in the case of the agent M a2 . 
In order to avoid unneeded redundancies we assume a\ < a 2 ■ Let us note that we 
have not included a special label to denote a failed passing of time because the 
observation of a system does not explicitly provide such information. In order to 
detect a fault in one of the agents included in a system (in this case, the IUT) we 
will need to check whether the observed behavior matches a possible behavior of 
the specification of the system in which such an agent produces no failure. This 
can be done by checking whether the observed trace belongs to the set of valid 
traces of the specification for that agent , that is, those for which that agent does 
not fail. 2 However, we must take into account that the traces of the specification 
include information about the internal behavior of the system. Thus, we must 
first identify the set of visible traces of the specification. Intuitively, a trace 
becomes visible after removing all the events related to the modification of the 
states and by joining all the consecutive passing of time transitions together into 
a single one. In the following definition, we identify the set of observable traces 
of a system. We will require that the behavior of one of the USMs included in the 
system is free of failures. The reason is that our aim is to identify the observable 
traces of a system consisting of a specification and a test where the behavior of 
the specification is correct. By comparing them with the traces of the system 
consisting of the IUT and the test we will be able to detect failures in the IUT. 

Definition 15. Let S = (Mi, . . . ,M m ) be a system, let 1 < i < m, and let 
a £ ValidTraces(S,c, Mi). The observable trace of the trace valid for Mi a, 
denoted by OTr(a, Mi), is defined as OTr’(a,Mi, 0), where 



f [(*,/?)] 



OTr’(a , Mi,t) = < 



0Tr’(l',Mi,t) 
OTr’(l ' , M u t + f) 



, (t, (3) : ( x , (ai, a 2 ), 7) : OTr ’(V , Mi, 0) 



if CT=[] 

if a = (c' , c", 0) a : l 1 

if cr=(c' ,c" ,t')p A :V A 
A 

if cr=(d! , d" , 0) T : /' 



where 




((^17 fl_l ^ 1)7 • * • 7 ('-’ai 7 ? ai7 ^01)7 • * • 7 (^a 2 ’ ^0-2 

(Oi , r'l, I'l), • • • , « , c , I'aJ, ■ ■ ■ , (s' a2 ,r^,la 2 ) , , (s' m ,r£ 



I’m)) 

I’m)) 



and x = - r' ai . 

Let S = (Mi,...,M m ) be a system and c a configuration of S. We de- 
fine the set of observable traces of S from c for a valid Mi, denoted by 
ObsTraces(S , c, Mi), as {a' \ 3 a £ ValidTraces(S, c, Mf) : a' = OTr(a, Mi)} . 

□ 

Now that we can compute the observable traces of a system specification, we 
can detect whether the observable behavior of a IUT represents a faulty behavior. 

2 Let us remark that we only require that the behavior of the IUT is free of faults, as 
a fault of the test does not mean the incorrectness of the IUT. 
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A trace observed in the composition of the IUT and the test represents a fault 
if it does not belong to the set of observable traces of the system consisting of 
the (non-failing) specification and the test. 

Definition 16. Let S = (Spec, Test) be a system where Test is a test to guide 
the specification Spec through a given path p. Let a" be an observable trace of 
a real system RS consisting of an IUT and the test Test. Let c denote the initial 
configuration of S. We say that a " represents a fault of the IUT with respect to 
Spec if a" qL ObsTraces(S,c, Spec). □ 

4 Conclusions and Future Work 

In this paper we have presented a framework to test agents whose underlying 
model is given by a utility state machine. The main highlight of our active testing 
approach is that tests, in contrast with the usual situation, are also given by 
agents. This paper together with [13] firmly sets the basis for a formal model to 
deal with autonomous commerce agents. However, we consider that further work 
on this topic should follow to complement and extend the existing framework. 
First, other notions of testing should be explored. In particular, we are working 
with a more passive approach where an agent is simply observed. Second, we 
think that in order to asses the usefulness of our framework it is necessary to 
deal with other agent-based e-commerce systems (as we have done with Kasbah) . 
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Abstract. Internet software tightly integrates classic computation with 
communication software. Heterogeneity and complexity can be tackled 
with a component-based approach, where components are developed by 
application experts and integrated by domain experts. Component-based 
systems cannot be tested with classic approaches but present new prob- 
lems. Current techniques for integration testing are based upon the com- 
ponent developer providing test specifications or suites with their compo- 
nents. However, components are often being used in ways not envisioned 
by their developers, thus the packaged test specifications and suites can- 
not be relied upon. Often this results in conditions being placed upon 
a components use, however, what is required is a method for allowing 
test suites to be adapted for new situations. In this paper, we propose 
an approach for implementing self-testing components, which allow inte- 
gration test specifications and suites to be developed by observing both 
the behavior of the component and of the entire system. 



1 Introduction 

Software for the Internet often presents a strong integration of computation, data 
and communication aspects. Classic software products are often deployed and 
tested independently from communication services that are accessed as external 
libraries. In many Internet applications, such as e-commerce software, commu- 
nication aspects cannot be easily separated from traditional software, but must 
be tightly integrated in the product. Such integration of heterogeneous aspects 
results in new development and testing challenges. 

A popular approach for addressing complexity and heterogeneity relies on the 
use of components and component-based design methodologies. Components en- 
hance reuse and can facilitate the sound integration of heterogeneous services. 
Components can be developed by different teams with specific expertise and 
abilities: communication experts may focus on communication services, while 
software and integration experts may focus on traditional data and computa- 
tional aspects. 

* This work has been partially funded by a grant from the SegraVis Research Training 
Network - www.segravis.org. 
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The independent development of reusable components and the adoption of 
component-based methodologies introduce new verification challenges that de- 
rive from the absence of knowledge about the final system when developing 
components, and about the components’ internals when developing the target 
application. Good components are widely re-used, and component designers can- 
not anticipate all possible uses at development time. System designers should be 
able to reuse components without knowing all internals to benefit from compo- 
nent developers’ expertise. Test designers must be able to test single components 
independently from the applications, and component-based systems without ac- 
cessing the internals of their components. 

The scientific community is investigating various solutions to these new ver- 
ification challenges: providing components with an associated specification [1], 
deploying together the component with its test suite [2], or developing compo- 
nents with testing facilities [3] . 

The approaches investigated so far work under specific hypotheses on both 
components and their integration, and thus inevitably restrict the use of compo- 
nents and may fail when the verification hypotheses are violated. In this paper, 
we propose a novel approach that tries to overcome these limitations by moving 
testing from development to deployment time. The proposed approach is based 
on self-testing components, a method successfully exploited in hardware design: 
components are augmented with self-testing capabilities that can be exploited 
when the components are reused in a novel system. However, self-testing fea- 
tures are targeted at testing for chip malfunctions and the assumption is made 
for hardware components that the functionality of the component is sound. Self- 
testing components can self-verify their behavior in the new context and thus in 
principle can be reused without any a-priori limitation. 

We propose a framework that generates self-testing features from compo- 
nents’ test and execution. When testing and using components in traditional 
settings, we capture components’ executions, and distill Invariants that model 
the components’ behavior as experienced during execution. These Invariants 
provide the information for generating test cases that can be automatically ex- 
ecuted when components are reused in new systems. Thus new systems can 
be tested without restricting components’ reuse or requiring specific knowledge 
about components. 

Section 2 presents the basic idea underlying self-testing components. Sec- 
tion 3 describes how we derive the Invariants that we use for generating test 
suites associated to components. Section 4 presents the different techniques that 
we developed for filtering test cases for self-testing. Section 5 discusses the prob- 
lems of executing self-tests. Section 6 highlights the advantages of the new ap- 
proach presented in this paper comparing it with related work. Finally, Section 7 
outlines on-going and future work seeded by the technique proposed in this pa- 
per. 
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2 Self- Testing Components 

Components are usually produced by different software vendors and are then 
assembled by component deployers, to build the final system. Component de- 
velopers know neither the context of the components execution nor the ways 
in which they will be used. Moreover, component developers implement compo- 
nents under implicit assumptions regarding the behavior of other components 
that may be violated in certain environments. 

Component integrators have limited knowledge of the reused components, 
since components are often deployed either without or with incomplete speci- 
fications and the source code is seldom provided. Integration testing becomes 
difficult, and does not always provide a sufficient level of confidence in the final 
system. Many major failures confirm the difficulties in achieving an acceptable 
level of confidence even in critical scenarios, for example the Mars Climate Ob- 
server [4], the Mars Polar Lander [5] or the Arianne 5 [6] problems. 

In hardware testing, some of these problems have been addressed by devel- 
oping Built-In Self- Test (BIST) features. “BIST is a Design-for-Testability tech- 
nique in which testing (test generation and test application) is accomplished 
through built-in hardware features” [7] . BIST features are automatically derived 
from the design, and system integrators do not have to care about component 
testing since it is automatically performed by BIST features. The same idea can 
be extended to software components by producing self-testing components , i.e., 
components which automatically test their integration in a larger system. 

Self-testing software components differ from BIST hardware both for: the 
time of test execution, and the type of tests that are performed. In the case of 
testing hardware components, test cases are executed regularly to check for faults 
that may arise due to chip problems, while tests for software components are 
executed only once at deployment time since software components do not change 
during their lifetime (unless they are replaced with newer versions). Moreover, 
since hardware can degrade its performance or stop working correctly, BIST 
embedded features refer mainly to unit testing, whilst, in the case of software 
components, it is more important to consider integration tests since unit testing 
is performed during development. 

There are several ways to implement self-testing components: by embedding 
specifications [8], by adding testing functionalities into the component [3], and by 
associating test suites to components [9] . This work suggests various approaches 
and provide encouraging preliminary results. Our work enhances the previous 
solutions proposing a novel approach for generating test cases to create self- 
testing components. 

The successful execution of all test cases associated with a component C 
newly integrated in a system assures that C integrates correctly into the system, 
i.e., the interactions from C to the system are correct. The successful execution 
of all test cases associated with components that interact with C assures that 
the system integrates well with C, i.e., all interactions from the system to C are 
correct. Insights regarding the execution of test cases are provided in Section 5. 
Self-testing components present several advantages: 
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— System integrators who operate with classic components need to design in- 
tegration test strategies without knowing details of each single component; 
while with self-testing components integration tests are obtained automati- 
cally. 

— Self-testing components do not require the generation of test cases for each 
new system. 

— Self-tests can be automatically re-executed for testing the correctness of 
modifications without additional effort. 

— Self-testing components can be augmented with oracles derived from execu- 
tions in previous systems, thus reducing the need for additional scaffolding. 

Test suites associated with self-testing components can be derived in different 
ways: 

— The test suite can be manually provided by the component developer [10]. In 
this case the test suite is generated by using the experience and intuition 
of the component developer without using any explicit criterion. This brute 
force approach takes advantage of the ability of the developer, but rarely 
meets the requirements of soundness and completeness. 

— The test suite can be generated from (formal) specifications [11]. In this 
case a specification of the software component is provided from which the 
test suite is generated. Whilst this method produces test suites which are 
highly effective it is reliant upon the existence of an accurate and complete 
specification. 

— The test suite can be generated from component executions [12]. In this case 
the test suite is obtained by observing previous executions, selecting mean- 
ingful ones, and then storing them in a repository. This case is dependent 
upon the component being used completely during observation. Therefore 
the longer the component is observed the more likely it is for coverage to be 
obtained. 

Our approach to creating self-testing components is based upon an amal- 
gamation and extension of the second and third methods. A specification, in 
the form of derived/inferred properties, is generated from either source code or 
observed executions. This specification can then be used to filter observed exe- 
cutions to be used as test cases. Our proposed method has the following benefits 
over the previous methods: the technique (1) can be used on binary compo- 
nents, e.g., when a third party component is purchased, (2) is very practical, 
thus it requires little effort by either the component developer or the component 
assembler, and (3) is for the large part automatic. 

Our approach is based on three main phases: 

Generating Invariants: in this phase, we generate both proper and likely In- 
variants. Proper Invariants are generated from statically analyzing the source 
code, and describe properties of interactions of the component with the sys- 
tems it is used in. Likely Invariants are automatically generated by moni- 
toring the component behavior when integrated in running systems, and de- 
scribe both interactions and exchanged values between the component and 
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the embedding systems. Invariants provide the information required during 
the test generation phase to discriminate relevant behaviors that are selected 
as interesting test cases. 

Recording Behaviors: in this phase, we record behaviors during normal ex- 
ecutions of systems that embed the target component, to gain information 
that can later be used for generating test cases. 

Generating Test Suites: in this phase, we generate test suites by sampling 
the set of collected behaviors according to the recorded Invariants. 

The main contribution of this paper is first in assembling previously exploited 
technology to derive Invariants and record behaviors and then in proposing a set 
of criteria to sample the space of behaviors for selecting test suites. 

3 BCT Framework 

The BCT Framework [13] is a suite of tools that we use to monitor and dy- 
namically verify components. BCT dynamically extracts information regarding 
components’ behaviors as Invariants and records actual behaviors. We will show 
in the next sections how to use this information to generate test cases. 

Invariant Generation 

The information extracted during component monitoring consists of a specifica- 
tion of components interactions in the form of Interaction and I/O Invariants. 
Interaction Invariants describe the protocol that the monitored component uses 
to communicate with the other components. I/O Invariants describe what infor- 
mation is passed between components. 

Interaction Invariants represent the pattern of interactions of each service of 
a component with other components. These Invariants are captured at run-time 
as a finite state machine which can then be expressed as a regular expression. For 
instance, the Interaction Invariant associated to a service viewCart of a Cart 
component for webshop applications can be: 

(Catalog. getltemDetail (ImageUtility . loadlmage |e) ) * 

and indicates that visualization of the content of the Cart causes from 0 to n in- 
teractions with the Catalog component for retrieving detailed information about 
items. For each item in the cart, an additional interaction with the ImageUtility 
component may be required if a picture of the item is provided. 

Regular expressions consist of elements of the alphabet, and operators. The 
alphabet represents interactions with other components. In the context of Inter- 
action Invariants two operators are used. | is the union operator which specifies 
that either the left or right symbol can be matched, and * is the Kleene operator 
which specifies that the previous symbol can be matched 0 or more times. In the 
example a * (6|c) the alphabet consists of {a, 6, c} while the operators {*, |} are 
used. 



342 



Leonardo Mariani et al. 



We derive Interaction Invariants both statically and dynamically. We stat- 
ically generate Interaction Invariants by building a reduced control-flow graph 
where nodes represent services requests. A regular expression can then be in- 
ferred from this graph. We dynamically generate Interaction Invariants by mon- 
itoring the components interactions with the system, further details can be found 
in [13, 14]. Static generation produces Interaction Invariants which represent all 
possible interactions of a components. This is in contrast to dynamic generation 
which produces Invariants representing only the observed behaviors of a compo- 
nent. 

I/O Invariants represent properties over parameters of the components in- 
teraction with the system. For example, an Invariant qt > 0 associated to the 
interaction of a service addltem of a component Cart by a service buyltem of a 
component Purchase indicates that variable qt (item quantity) is always positive 
when the service is invoked in that context. 

We derive I/O Invariants dynamically by monitoring the execution of a com- 
ponent. Thus, I/O Invariants are Invariants over observed executions, that repre- 
sent “likely” Invariants for the target component. Further information regarding 
how state data is extracted from complex objects can be found in [13, 14]. 



Recording Observed Behaviors 

The BCT Framework has the facility to record observed behaviors of a compo- 
nent. An observed behavior consists of some form of stimulus to the component 
as well as its effect in the form of an interaction trace (the sequence of interac- 
tions triggered by the stimulus) and I/O values. These observed behaviors can 
be stored allowing them to be used as test cases for integration testing. However, 
indiscriminately storing these behaviors will soon produce large test suites that 
are of no practical use. Therefore, it is necessary to define filtering criteria for 
distinguishing which behaviors are meaningful or more specifically those likely 
to expose integration faults. These filtering criteria are presented in Section 4. 



4 Test Case Selection 

The monitoring of a component records a set of observed behaviors which can 
be used as possible tests. We produce test suites by extracting a subset of this 
set according to suitable filtering criteria. These filtering criteria utilize the gen- 
erated Invariants as a specification of the components behavior. Our filtering 
criteria differ from classic testing methodologies in that we do not intend to test 
the components compliance to the Invariants, instead we use them as a means 
of identifying meaningful test cases. In this context we refer to a “meaningful 
test case” as one likely to expose integration faults. 

In this section we propose a number of filtering criteria based upon the gen- 
erated Interaction and I/O Invariants. These filtering criteria can be further 
categorized as those based upon post-execution filtering and those performed 
during the process of generating the Invariants. 
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Fig. 1 . The finite state machine that is equivalent to the regular expression a*b(b\c). 
The node with the string incoming edge represents the initial state, while the node 
with the double border represents the final state 



Filtering criteria based on Interaction Invariants can be defined for Invariants 
expressed as either regular expressions or the corresponding finite state machines. 

Three entities can be considered in a regular expression: the alphabet, the op- 
erators, and possible subexpressions. We therefore propose three filtering criteria 
based upon each entity: 

Alphabet Coverage: A test suite TS satisfies the Alphabet Coverage criterion 
if for each symbol a in the alphabet, there is at least a test case TC in TS 
that contains a. 

For example, the test suite {abc} satisfies the alphabet coverage for the 
regular expression a*b(b\c). 

Executing a test suite that satisfies alphabet coverage results in exercising 
all services accessed by the component-under-test at least once. 

Operator Coverage: A test suite TS satisfies the Operator Coverage criterion 
if 

— for each union operator | occurring in the regular expression, TS includes 
at least one test case TC a that contains the first operand and one test 
case TCb that contains the second operand. 

— for each Kleen operator * occurring in the regular expression, TS in- 
cludes at least one test case TC a that corresponds to no iterations of the 
operand, one test case TCb that corresponds to exactly one iteration of 
the operand, and one test case TC c that corresponds to more than one 
iteration of the operand. 

For example, the test suite {bb, abc, aabb} satisfies the Operator Coverage 
criterion for the regular expression a*b(b\c). 

Expression Coverage: A test suite TS satisfies the Expression Coverage cri- 
terion if for each choice of operators that results in a sentence S up to 
consecutive iterations of the Kleen operators, it contains at least one test 
case TC corresponding to S. 

For example, the test suite {bb, be, abb, abc, aabb, aabc} satisfies the expression 
coverage criterion for a*b(b\c). 

Execution of a test suite that covers expressions result in the component 
executing each possible combination of behaviors. 

Three entities can be considered in a finite state machine (FSM): nodes, edges 
and paths. We therefore propose three filtering criteria based upon each entity: 
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Node Coverage: A test suite TS satisfies the Node Coverage criterion if for 
each node n of the FSM there is at least one test case TC that traverses n. 
For example, the test suite {66} satisfies the Node Coverage criterion for the 
FSM in Figure 1. 

Execution of a test suite that satisfies the node coverage criterion corresponds 
to covering all states of the component-under-test where a decision about the 
next interaction can take place. 

Edge Coverage: A test suite TS satisfies the Edge Coverage criterion if for 
each edge e of the FSM there is at least one test case TC that traverses e. 
For example, the test suite {a66, a6c} satisfies the Edge Coverage criterion 
for the FSM in Figure 1. 

Execution of a test suite that satisfies the edge coverage criterion results in 
requesting the execution of all services accessed by the component-under-test 
at least once in each different situation. 

Path Coverage: A test suite TS satisfies the Path Coverage criterion if for each 
path p of the FSM there is at least one test case TC that traverses p. Cycles 
are covered according to the boundary interior criterion that limits path 
coverage to each different path contained within the cycle at least once [15]. 
For example, the test suite {bb,bc,abb,abc} satisfies the Path Coverage cri- 
terion for the FSM in Figure 1. 

Execution of a test suite that covers all paths results in the component 
executing all possible “linear indepedent” combinations of behaviors at least 
once. 

I/O Invariants describe properties over possible values of the parameters of 
a component’s service. We can therefore refer to the properties specified by I/O 
invariants to derive a new filtering criterion. White and Cohen proposed a test 
case selection criterion based on mathematical properties over variables [16]. 
Test cases selected by the White and Cohen criterion include stimuli that are 
both feasible and infeasible according to the specification. We propose a criterion 
that applies White and Cohen criterion to our set of I/O Invariants. We restrict 
the criterion to feasible stimuli only, since it is not possible to observe infeasible 
stimuli at run-time. The obtained filtering criterion is: 

Domain Value Coverage: A test suite TS satisfies the Domain Coverage cri- 
terion if for each I/O Invariant it contains at least one test case corresponding 
to both boundary and normal values as shown in Table 1 

All filtering criteria defined so far are applicable to a set of observed be- 
havios that derive from previously recorded executions. We identify them as 
post- execution criteria. 

Recording a large set of executions may be space consuming. Therefore, we 
define additional criteria that can be used at run time, thus reducing the set 
of executions to be recorded. We identify this new set of criteria as run-time 
criteria. 

We propose the following set of run-time criteria: 
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Table 1. Filtering criteria for I/O Invariants, x, y and 2 are variable names or se- 
quences; a , b and c are constants; fn is any language specific function; and — shows 
that no test cases are necessary to cover the Invariant 
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Test Case Spec 
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Interaction Invariant Modification: the test suite is built incrementally by 
adding all observed behaviors whose execution causes an Interaction Invari- 
ant to be modified. 

Interaction Invariant Modification with Observed Frequencies: this 

criterion extends the previous one by adding special cases corresponding to 
the Kleene operators. We add an observed behavior to the test suite if the 
behavior corresponds to a number of iterations of the operand of a Kleen 
subexpression not yet experienced. 
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I/O Invariant Modification: we incrementally add observed behaviors whose 
execution results in the modification of an I/O Invariant. This criterion is 
based upon the work of McCamant and Ernst [17]. 



Subsumption Relationship 

The filtering criteria we have proposed do not produce test suites that are mu- 
tually exclusive. In that certain criteria expand upon the coverage provided by 
others. We can therefore classify filtering criteria into a subsumption hierarchy. 
We define subsumption as: 

A filtering criterion C\ subsumes a filtering criterion C 2 if every test suite that 
satisfies C\ also satisfies C 2 . 

Figure 2 summarizes the relationships among the filtering criteria presented 
in this paper. The reasoning behind these relations is as follows: 

— The subsumption relationship between Alphabet Coverage, Operator Cover- 
age and Expression Coverage is quite obvious. As is the relationship between 
Node Coverage, Edge Coverage and Path Coverage. 

— Edge Coverage subsumes Alphabet Coverage as each edge in the FSM corre- 
sponds to different symbols. Thus covering all edges implies that all symbols 
are covered. 

— Operator Coverage subsumes Edge Coverage as operators are represented as 
edges. Thus covering all operators implies that all edges are covered. 

— Expression Coverage subsumes Path and Operator Coverage as it considers 
all possible combinations of behaviors. 

— Interaction Invariant Modification subsumes Edge Coverage due to the way 
in which Invariant modification is defined in [13]. In this definition a new 
edge is added if a new behavior is observed. Thus covering all modifications 
implies all edges are covered. 

— Finally, Interaction Invariant Modification with Observed Frequencies is 
a clear extension of Interaction Invariant Modification. 



5 Executing the Test Suite 

Integration testing focuses upon how components interact within the embedding 
system. Two forms of interactions can be observed: how a component uses the 
system, and how the system uses a component. Integration faults can occur in 
either or both situations. The first form of interaction can be tested by executing 
a test suite covering the Interaction and I/O Invariants of the component over 
the accessed services. The second form of interaction can be tested by executing 
test suites of all components that interact with the component. 

Components can be both stateless and stateful. Stateless components can be 
tested by simply invoking services over the tested component and checking the 
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Fig. 2. Subsumption relationship over the proposed filtering criteria 



result. Stateful components could be directly executed but since our test cases 
are extracted from observed behaviors of the component they are only valid when 
the system is in that state. Therefore, if actual state is different from the state 
at test case extraction time, the test case may not necessarily be compatible. 
Moreover, even if the state of the component has remained, the state of the 
system with which it interacts may have changed. Furthermore, if a test case 
was to fail, the tester does not know if it was caused by an integration error or 
a state error. 

One possible solution to distinguishing the type of errors is to prevent test 
cases from being executed if the current state is not applicable. This can be 
accomplished by packaging test cases with conditions that specify what state the 
component and system must be in. Whilst this approach prevents state errors 
from occurring it risks test cases not being executed negating the confidence in 
the test suite. 

The solution that we envision is to design the components for testability, by 
adding an interface that would facilitate the storing and resumption of state. In 
this way, it is possible to store the state of components involved in an execution 
and to resume them when necessary. Combining the existence of a repository 
of resumable states and query interfaces leads to the production of an effective 
framework for managing stateful components. 

The framework can be implemented with limited efforts on top of existing 
middleware that supports component persistency. In fact, some middleware al- 
ready provides features for storing and resuming the status of components as 
well as functionalities for querying the storage of status, for instance see the 
EJB framework [18] and the EJB-Object Query Language [18]. 
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6 Related Work 

The basic problems of testing component-based systems are summarized by 
Vitharana [19] . Vithrana highlights how even though individual components 
are tested in isolation, it is very difficult to rely upon this, and complex integra- 
tion testing is necessary to ensure the reliability of the system. 

Binder [20] introduces the concept of building testability directly into the 
objects of an object-oriented system during their development. This is achieved 
by a combination of approaches including formalized design and testing strategies 
and embedded test specifications. However, whilst this method is possible when 
the entire system is being developed within a single group, in component-based 
systems, it would require all of these approaches being standardized and adhered 
to by a number of different developers. 

Both Bertolino and Polini [2] and Martins et al [1] discuss different methods 
for making components self-testable. Their methods differ in that Bertolino and 
Polini package test cases with their components, whilst Martins et al require 
the user to generate the test cases. However, in both cases the test cases are 
generated from a developer defined test specification that is packaged with the 
component. We assume that components may be deployed in ways not previously 
envisioned by the developer. Therefore, pre-defined test specifications may no 
longer be valid. We address this situation by constructing test suites based upon 
the observed behaviors of the running system. 

Liu and Richardson [9] introduce the concept of using software components 
with retrospectors. Retrospectors record the testing and execution history of a 
component. This information can then be made available to the software testers 
for the construction of their test plan. Liu and Richardson retrospectors do 
not take into account automatic generation and execution of test cases since 
test case generation is entirely delegated to the system integrator. Moreover, 
the problem of dealing with state is not addressed. On the contrary, our self- 
testing components are deployed with test suites in a framework enabling their 
automatic execution, thus the system integrator does not have to generate the 
test cases. 

7 Conclusions and Future Work 

Component-Based software engineering is a promising approach for developing 
complex heterogeneous software systems that integrate classic computation and 
communication aspects. Testing component-based systems presents new prob- 
lems with respect to classic software systems, since components are developed 
with limited knowledge about their use, and system developers have limited 
information about the internals of the reused components. 

In this paper, we propose a new approach for automatically developing self- 
testing components. The proposed approach augments classic components with 
self-testing features by automatically extracting information from components 
when they are used as part of running systems. Automatically generated self- 
testing features support automatic execution of integration testing at deployment 
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time. In this paper, we focus on the problem of automatically generating test 
cases from behavior Invariants of components. 

We are currently developing a prototype for experimenting with self-testing 
components. Through this experimental work we aim to be able to evaluate the 
filtering criteria, specifically with reference to the fault revealing capability and 
the size of the test suite. 

Regarding the use of filtering criteria to create test suites, we do not expect 
to find a single ideal criterion. As with many situations within software engi- 
neering the choice of filtering criteria largely depends upon the intentions of the 
component developer or system integrator. For example, a developer construct- 
ing a component for an embedded system (where resources are limited) may 
prefer a test suite of minimal size whilst still covering all common integration 
errors. This is in contrast to a developer of a safety critical component who may 
prefer a test suite which covers all possible interactions and where test suite size 
is less important. We aim to evaluate each filtering criteria, highlighting their 
strengths and weaknesses, both generally and related to specific applications 
scenarios, e.g., enterprise components versus embedded components. We expect 
that this work will allow a developer to select the most appropriate filtering 
criteria for their specific application. 
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Abstract. Software Model-Checking and Testing are some of the most 
used techniques to analyze software systems and identify hidden faults. 
While software model-checking allows for an exhaustive and automatic 
analysis of the system expressed through a model, software testing is 
based on a clever selection of “relevant” test cases, which may be man- 
ually or automatically run over the system. 

In this paper we analyze how those two analysis techniques may be in- 
tegrated in a specific context, where a Software Architecture (SA) spec- 
ification of the system is available, model-checking techniques are used 
to validate the SA model conformance with respect to selected proper- 
ties, while testing techniques are used to validate the implementation 
conformance to the SA model. 

The results of this research are applied to an SDH Telecommunication 
system architecture designed by Siemens CNX. 



1 Introduction 

Testing and model-checking are between the most important techniques applied 
in practice to detect and fix software faults. 

Software Model-Checking [7] analyzes concurrent systems behavior with re- 
spect to selected properties by specifying the system through abstract modelling 
languages. Model-checking algorithms offer an exhaustive and automatic ap- 
proach to completely analyze the system. When errors are found, counterexam- 
ples are provided. The main limitations model-checking suffers are that it may 
only verify systems expressed through state-based machines, it is more limited 
than theorem proving, and it suffers of the state explosion problem. Moreover, 
model-checking may be difficult to be applied, since it usually requires skills on 
formal specification languages. 

Software Testing , instead, refers to the dynamic verification of a system’s 
behavior based on the observation of a selected set of controlled executions, or 



M. Nunez et al. (Eds.): FORTE 2004 Workshops, LNCS 3236, pp. 351—365, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 



352 



A. Bucchiarone et al. 



test cases [3]. Testing involves several demanding tasks. However, the problem 
that has received the highest attention in the literature is, by far, test-case 
selection: in brief, how to identify a suite of test cases (i.e., a finite set of test 
cases) that is effective in demonstrating that the software behaves as intended, 
or, otherwise, in evidencing the existing malfunctions. Clearly, a good test suite 
is the crucial starting point to a successful testing session. 

Comparing model-checking with testing analysis techniques, we may identify 
the following differences: i) while model-checking offers an exhaustive check of 
the system, testing is based on a clever selection of “relevant” test cases; ii) while 
model-checking is a completely automated process, testing is usually left to the 
tester experience; iii) while model-checking requires skills on formal methods, 
testing may not; finally, iv) while model-checking (usually) helps to find bugs 
in high-level system designs, testing (in its traditional form) identifies bugs in 
implementation level code. 

Considering the strong complementarity between those two worlds, we believe 
an integration between model-checking and testing may provide an useful tool 
to test modern complex software systems. 

In this paper we analyze how those two analysis techniques may be integrated 
in a specific context, where a Software Architecture (SA) [24, 11] specification 
of the system is available, some properties the SA has to respect are identified 
and the SA specification has been implemented. Model-checking techniques are 
used to validate the SA model conformance with respect to selected properties, 
while testing techniques are used to validate the implementation conformance 
to the SA model. In the context of this research, the model checker validates the 
SA conformance to functional properties, while the testing approach provides 
confidence on the implementation fulfillment to its (architectural) specification 
(i.e., the so called “conformance testing”). 

The advantages we expect are manifold: we apply the model-checking tech- 
nique to higher-lever (architectural) specifications, thus governing the state- 
explosion problem, while applying testing to the final implementation. We check 
and test the architecture and the system implementation with respect to archi- 
tectural (functional) properties. Moreover, the test case selection phase is driven 
by the architectural model. In Siemens CNX systems this approach allows to 
unify some design steps: in fact, differently from current practices, test cases 
may be derived from an architectural model, which has been previously checked 
to be compliant to a set of functional requirements thus ensuring a continuous 
process from the design step to the integration testing phase. 

In proving the validity of this idea, we use the model-checker SPIN in con- 
junction with the Charmy framework [6], and apply this approach to a Siemens 
CNX application. 

The following Section 2 motivates our research work by describing some ex- 
istent related work. Section 3 describes our proposal, by outlining how model- 
checking is currently used to validate properties on an architectural model and 
how current testing methodologies allow to test the source code conformance 
with respect to architectural decisions. The approach is applied to a Siemens 
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CNX telecommunication application in Section 4, by providing preliminary re- 
sults. Section 5 draws some considerations while Section 6 concludes the paper 
and outlines future work directions. A list of abbreviations is provided at the 
end of the paper. 

2 Motivations and Approach Outline 

Many work have been developed in using model-checking to generate test 
cases [1, 12, 5, 22, 14]. The key idea that connects these two validation techniques 
is to generate, by using model checker features, counter-examples successively 
used to derive test cases. 

The generation of counter-examples is obtained identifying (from the re- 
quirements) the properties that the system must satisfy. Actually, to obtain test 
cases the focus must be put on negative requirements, thus the model checker 
can generate counter-examples automatically turned into executable tests. Typ- 
ically, the properties negation is obtained by using the mutation technique [10] 
where a mutation is a small syntactic change in the state machine or in the prop- 
erty. A mutant model is obtained by a single mutation operator on the original 
model. The rationale is to generate test cases for the critical parts of the system. 

Unfortunately, the automatic test generation process (by applying model- 
checking) is not mature in the software industry, for several reasons: 

PI : due to models complexity, the model checker techniques become 
inapplicable, thus not allowing to identify test cases; 

P 2 : even on little examples, the number of generated test cases causes 
the intractability; 

P3 : as underlined also by [12] one of the drawback is on assuming the 
existence of the properties as part of the problem specification. 

In this paper we propose a solution which covers problems PI and P 2 by 
combining model- checking and testing at different abstractions level. Problem P 3 
is also taken into account when using the proposed model-checking approach. 

As graphically shown in Figure 1, we use model-checking (MC) techniques in 
order to validate the architectural model conformance with respect to identified 
functional properties, and a testing approach which selects test cases driven by 
the architectural models and the model checking results. The combination of 
SA-level model-checking and SA-based code testing allows to guarantee that the 
architecture correctly reflects important requirements and the code conforms to 
the software architecture specification. 

This approach produces two benefits: by using an incremental process which 
allows to specify the architecture, model-check it and refine critical sub-parts, 
we are able to punctually identify details of subsystems identified as critical, 
working always with smaller models. Together with the fact that model checking 
is applied to an high-level model (the SA), we reduce the complexity of the 
model to be analyzed, thus limiting the state explosion problem (i.e. , PI). We 
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Fig. 1. Approach outline 



gain then precision in selecting test-cases maintaining tractable models in terms 
of dimension and verification time. 

3 Our Proposal 

The approach we are proposing is composed by two correlated activities: val- 
idating SA specifications with respect to functional properties through model- 
checking, and using such models and results to drive an SA-based code testing 
approach. In the following sections we describe both activities (in Section 3.1 
and 3.2) and how to move from the one to the other. 



3.1 Validating Architectural Specifications: The Charmy Approach 

In recent years, the study of Software Architecture (SA) [13, 11] has emerged as 
an autonomous discipline enabling the design and analysis of complex distributed 
systems through suitable abstractions. SAs support the formal modeling of a sys- 
tem, through components and connectors, allowing for both a topological (static) 
description and a behavioral (dynamic) one. 

There is not a unique way to specify an SA, and one of the most challenging 
tasks is on analyzing functional and non functional properties on the selected 
architecture [19, 11]. Naturally, a good architecture is the one which satisfies at 
best the system requirements, acting as a bridge between the requirements (the 
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planned architecture must satisfy) and the implementation code (which has to 
reflect architectural properties), as advocated in [13]. 

Charmy is a framework that, since from the earlier stage of the software de- 
velopment process, aims at assisting the software architect in designing software 
architecture and in validating them against expected properties. 

We start specifying an initial, prototypal and even incomplete SA which 
may identify few (main) components and a set of high-level properties. From 
this specification we obtain an initial model that can be validated with respect 
to significant high-level behaviors. This first validation step allows us to gain 
confidence on the global architectural design and choices, and to identify portions 
of the SA that might need further and deeper investigation. In fact, when an 
inconsistency is identified (by producing a counter example), the SA specification 
may be refined by focussing on relevant system portions. The process is iterated 
until any critical sub-part is deeply analyzed. 

To some extent, our approach is similar to extracting test cases. In eliciting 
test cases a tester focusses on the critical parts of the system in order to verify 
his intuitions. In the same way we elicit the properties that represent potentially 
critical flows and check them on the system model by using model checking 
techniques. 

State machines and scenarios are the source notations for specifying software 
architectures and behavioral properties they should satisfy, respectively. 

Charmy analyzes these models in order to automatically generate two differ- 
ent outputs, successively used for model-checking purposes. Figure 2 graphically 
summarizes how the framework works: 

— In Step 1, component state machines are automatically translated into 
a Promela formal prototype. The translation algorithm makes also use of 
extra information (embedded in the state machine specification) in order to 
identify which kind of communication is required. SPIN standard checks over 
Promela may be performed [16] ; 

— In Step 2, scenario specifications (in the form of extended Sequence Dia- 
grams) are automatically translated into Biichi Automata [4] . Such automata 
describe properties should/should not be verified; 

— Finally, in Step 3 the model checker SPIN evaluates the properties validity 
with respect to the Promela code. If unwanted behaviors are identified, an 
error is reported. 

Charmy is tool supported and offers a graphical user interface to draw state 
diagrams and scenarios, a plugin which allows to input existing diagram in the 
XMI format, and a translation engine to automatically derive Promela code and 
Biichi Automaton. For more information on the Charmy project, please refer 
to [6]. 

3.2 Software Architecture-Based Code Testing 

Having a software architecture validated whit respect to functional requirements 
is not enough. In fact, when the architectural information is used to drive the 
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source code realization, we need to validate the implementation conformance to 
the architecture. 

SA-based testing is a particular instantiation of specification-based testing, 
devoted to check that the Implementation Under Test (IUT) fulfills the (archi- 
tectural) specifications [23, 2]. The abstraction provided by a SA allows testing 
to take place early and at a higher-level. The SA-based testing activity allows 
the detection of structural and behavioral problems before they are coded into 
the implementation. Various approaches have been proposed on testing driven 
by the architectural specification, as analyzed in [20]. 

The approach we propose spans the whole spectrum from test derivation 
down to test execution. Our approach is based on the specification of SA dy- 
namics, which is used to identify useful schemes of interactions between system 
components, and to select test classes corresponding to relevant architectural 
behaviors. The goal is to provide a test manager with a systematic method to 
extract suitable test classes for the higher levels of testing and to refine them 
into concrete tests at the code level. 

In this paper we instantiate/adapt the general SA-based testing framework 
proposed in [20] (graphically sketched in Figure 3, steps 0-4) to be integrated 
with model checking techniques. In particular, we here provide guidelines on how 
the integration happens. Both Figures 1 and 3 will help understanding the idea: 

— Step A: the SA is specified through the topology and state diagrams pro- 
duced in Section 3.1 following the Charmy approach; 

— Step B: when in Charmy subsystems, considered critical, are identified for 
further analysis, we intentionally restrict our visibility of the system behav- 
iors by removing “not interesting” behaviors from the original system. To 
some extent, this approach is similar to extracting test cases. In eliciting test 
cases a tester focusses on the critical parts of the system in order to verify 
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his intuitions. In the same way, we elicit the properties that represent po- 
tential flows and check them on the system model by using model checking 
techniques. 

— Step C: when model-checking is run, we may have two different results: 
the system property of interest is not verified (NOK label in Figure 1), 
thus counter-examples are found, or it is verified (OK label in Figure 1). In 
traditional approaches where model-checking is used to identify test cases, 
counter-examples are generated (by producing properties negation) and au- 
tomatically turned into tests. In our context, even when a property (i.e., 
a scenario) is verified on the architectural model (i.e., the Promela model), 
it may be still of interest as a test case. In fact, since we span from SA 
checking to code testing, both OK and NOK results are of interest. When 
a NOK happens, it may depend on two different reasons: the architectural 
model does not conform to the property (thus we refine the architectural 
model in order to make it compliant to the functional property (Figure 1)) 
or we checked the negation of a formula (i.e., NOK means that the property 
is verified, similarly to what happens in the mutation technique). In some 
cases, we may still use the counter-example to test if the code conforms to 
the SA. When an OK result is found, we may simulate the system in order to 
produce more detailed scenarios which satisfy the property. In fact, we need 
to remember that the property we wish to verify may be very high-level, 
by missing many details. Through the simulation process, we may identify 
more detailed scenarios which very the high-level property on the architec- 
tural (Promela) model. A Test Generator Engine (TGE) (Figure 1) may be 
used to select only a (relevant) portion of the generated scenarios. The most 
simple algorithm for a TGE may select just a scenario for each OK property 
and the NOK scenarios. More precise algorithms may be identified; 

— Step D: following the current Siemens CNX practices, such detailed scenarios 
(called test specifications) may be used to manually or automatically derive 
executable tests. 



4 Proposal Application 

to a Siemens Telecommunication System 

In this section we apply the approach just described to a real system developed 
in Siemens CNX. We initially outline the Siemens’ design process , thus we de- 
scribe the standard telecommunication functional model in Siemens, as a way to 
formally describe the SA of telecommunication systems. We thus select, among 
the set of relevant architecture components we apply the proposed approach, the 
Engineering Order Wire (EOW) application , as an example to show some initial 
results (in Section 4.1). 

In currently applied practices in Siemens CNX, SA and tests design are two 
parallel activities starting from the system requirements specification. Then two 
different teams analyse system requirements and divergencies are possible caus- 
ing errors caught late during the test execution phase. A strong review process 
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(time consuming) is adopted to align all the design phases, eliminating the most 
part of such type of errors. The application of the MC techniques to validate 
SA provides a set of simulation results that can be used as a base to define 
tests. Defining tests in this way unify some design steps. In particular, deriv- 
ing test traces from MC formal verification of system architecture compliance 
to the requirements, guarantees consistency of the whole project and, virtually, 
eliminates the need of the review process. 

The standard telecommunication functional model in Siemens is the Syn- 
chronous Digital Hierarchy (SDH), a well defined standard by ETSI and ITU-T. 
Following the standards, a “Functional Model” (for an SDH system) describes 
the way an equipment accepts, processes and forwards information contained in 
the transmission signal, defining the internal processes, the internal and exter- 
nal interfaces, the supervision and the performance criteria and relevant recovery 
actions 

The functional model is built around two specific concepts: “network layer- 
ing”, with a client/server relationship between adjacent layers, and the “atomic 
functions” , to specify the behaviour of each layer. 

A network layer is a set of processing and supervision functions described 
by atomic functions, related to a specific set of transmitted information. Each 
layer faces to a couple of adjacent layers: a server layer, which provides transport 
services to the current layer, and a client layer which uses the transport services 
the current layer provides. Figure 4. a shows some different layers. 

Each layer is a group of atomic functions (as shown in Figure 4.b) . Three basic 
atomic functions are defined: connection, termination and adaptation functions. 
They are combined on the basis of combination rules. In addition, application 
functions (performing specific tasks) should reside at the top of a specific layer 
as shown for the EOW function in Figure 4. 

A network element (NE), i.e. a node in the SDH network, is a combination of 
network layers, thus composed by many atomic functions distributed in different 
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Fig. 4. SDH Layers and Atomic Functions 



layers and relevant application functions. Many NE may be interconnected and 
each atomic function (in a specific layer in a NE) is directly related in a peer-to- 
peer connection to an identical function, in the same layer but in a different NE. 
In other words, a direct “virtual network connection” between the two relevant 
mate functions is created by the transport services. 

EOW is an application on top of a specific SDH layer. The EOW application 
supports a telephone link between multiple NEs by using dedicated voice link 
channels defined on the SDH frame. An EOW node is represented by the EOW 
application implemented by a SDH NE. An EOW network is an overlay network 
over the SDH network (using the previously mentioned voice link channel). The 
EOW network is a switch circuit interconnecting several EOW nodes. 

An EOW network defines a Conference. An EOW node may participate on 
an EOW conference by being connected to an EOW network by means of EOW 
ports. An operator (sometime called subscriber) interfaces the EOW functional- 
ities by means of a handset device. The EOW procedures allow an operator to: 
i) make a call dialling a selective number, ii) receive a call, iii) enter a conference 
(with the special number-sign key) when a call is already in progress, and iv) 
exit the conference (cleanly terminate a call). 



4.1 Properties Verification with Charmy 

and Test Specification Selection: Initial Results 

Given the EOW application and the SDH telecommunication functional model, 
we initially identified some of the functional properties the EOW application 
should conform to, and in parallel, we defined an architectural model. 

Based on the EOW specification, we identified four functional requirements 
the system has to satisfy: 

— Requirement 1 and 2: when an operator makes a call dialling a selective 
number, the target operator must receive the call. 
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— Requirement 3: it must be possible to enter a busy conference (with the 
special number-sign key) when a call is already in progress. 

— Requirement 4: It must be always possible to exit to the conference (cleanly 
terminate a call) . 

We also abstracted away many details of an SDH network and EOW ap- 
plication, and produced an architectural model where each network element is 
abstracted into a couple of architectural components (the Conf erenceManager 
(CM) and the Handset (HS) components) while a connector is used to simulate 
the network connections (the EOWSubNetwork). A network model, composed by 
several network elements, is then abstracted as a set of component instances 
which may communicate through a connector. 

The CM interfaces the EOW network, through ports, by sensing embedded 
signalling to capture incoming calls and taking into account the conference status 
(free: when no subscribers are in conference; busy: when calls are in progress). 
The HS component interfaces and manages the external physical device used 
by the subscriber. It senses for hook status and key digit pressed and evolves 
through different internal states to cleanly manage the outgoing and incoming 
call sequences and signalling taking in care the speech channel connection to 
the conference. In the following, we take into consideration an EOW network, 
virtualized by means of a connector component (the EOWSubNetwork), with three 
node instances. Figure 5 shows the EOW architectural configuration of interest. 
We opted for a configuration with three node instances since this is the minimum 
configuration required to validate any of the system properties. 

Given the architectural specification in Figure 5, the four requirements/ prop- 
erties to be proven have been formalized in the form of Charmy scenarios. The 
notation used in Figure 6 is the Charmy notation for modeling scenarios where 
messages are typed with prefix e: or r.\ Notation details may be found in [17]. 

— Requirement 1 and 2: if the HS1 component dials the number to call the 
HS2 component ( eouiKeyDigit ), then component EOWSubNetwork must send 
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a callRequest message to the Conf erenceManager2 component that must 
send call2 to the HS2 component. 

— Requirement 3: if the HS3 component makes an off Hook then it must send 
the localNumSign3 to the Conf erenceManager3 to enter the conference. 

— Requirement 4: if HS1. HS2 and HS3 components terminate the call in 
progress, they must send the localNumSign and perform the internal op- 
eration onHook. 

By using the Charmy tool, the three scenarios have been automatically 
translated into Buchi Automata while the architectural state machine model 
has been translated into Promela code. SPIN has been run and no errors have 
been detected. This initial analysis (realizing the top part of Figure 1) gives us 
the assurance that the identified architectural model correctly reflects the three 
expected behaviors. 

In the following of this section, we describe how test specifications may be 
extracted (thus implementing the mid portion of Figure 1) through simulation. 

We thus simulate the Promela prototype obtained from the Charmy tool, 
through the use of the SPIN interactive simulation feature. This feature allows to 
simulate the Promela model, starting from the model initial state, and selecting 
a branch at each nondeterministic step. We thus started simulating the Promela 
prototype by reproducing the properties scenarios previously presented. Through 
interactive simulation, we are able to get a more detailed description of each 
scenario, with possible sub-scenarios. 

Applying the interactive simulation on the EOW model, driven by the first 
property (Requirements 1 and 2 in Figure 6), we obtained the following test 
specifications: 

Configl -> 

[onHookl , 

offHookl -> onHookl] -> 
of f Hookl -> 

1 _ , 

(cbusy==true) -> onHookl -> offHookl, 

(cbusy==f alse) -> timeoutl -> onHookl -> offHookl] -> 

(cbusy==f alse) -> eowKeyDigit ) -> callRequest2 -> 

*[Config2 -> offHook2 -> onHook2 -> offHook2 -> (cbusy==f alse) , 

Config2 -> offHook2 -> onHook2 -> offHook2 -> (cbusy==true) , 

Config2 -> offHook2 -> onHook2, Config2 -> onHook2 -> offHook2 -> 

(cbusy==f alse) , Config2 -> onHook2 -> offHook2 -> (cbusy==true) , 

Config2 -> offHook2] -> 



ca!12. 
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This textual description specifies many detailed scenarios (i.e., test specifi- 
cations) where “a -> 6” means a followed by 6, “[a,b]” means a XOR 6, “[_,b]” 
means null xor b , and “*a” means that a may happen everytime between the 
first and the last operation. Naturally, such test specifications are oriented to test 
no more than the property of interest, hiding any other (irrelevant) interleaving, 
and making the test specification more precise and concise. 

Following Figure 1, a Test Generation engine (to be implemented) will iden- 
tify a relevant subset of those test specs which will be converted in test cases 
by the Test Identification and Execution group in Siemens CNX and run on the 
EOW application. This activity will be analyzed in future work. 

In order to produce other relevant test cases, some refinements have been 
developed to improve the model, taking into account additional functional and 
non functional requirements like, DTMF embedded signalling, different calling 
type, EOW port configurations and so on. Such refinements are currently used 
to analyze the quality and advantages of the Charmy iterative specification and 
analysis process, and more mature results will be reported in future work. 



5 Some Considerations 

Differently from other approaches, we shown how model-checking and testing 
may be combined to span from requirements to SAs and finally to code. In 
our approach, since model-checking is used only to validate the architectural 
specification while test cases are executed over the final implementation, the 
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idea on how to identify test cases is different. While previous approach use 
model-checking counter-examples to derive test cases, we may use both verified 
and not verified scenarios. 

The main advantages our approach exhibits are listed in the following: 

— by applying model-checking at the architectural level, we reduce the model- 
ing complexity and the state explosion problem; 

— by using Charmy we may provide an easy to use, practical, approach to 
model-checking, hiding the modeling complexity; 

— the iterative model-checking approach proposed in Section 3.1 allows to iden- 
tify the most important properties to be validated, to refine the architectural 
model and finally to identify critical sub-systems and focus on them; 

— through interactive simulation we may identify traces of interest for testing 
the whole system or just a relevant subsystem. This guarantees a bigger 
synergy among model-checking and testing application. Since models are 
small enough, interactive simulation is possible; 

— the most important advantage, with respect to how testing has been previ- 
ously done in Siemens CNX, is that test specifications are identified from 
the architectural model (instead of directly from requirements) thus creat- 
ing a bigger synergy between software architects and testers, and eliminating 
the problem of keeping SA specification and Test specification aligned when 
requirements change. 

The proposed approach also suffers some limitations : currently, the Test Gen- 
erator engine shown in Figure 1 is not yet implemented. This means that the 
simulated traces need to be manually selected, while it could be automated. The 
generation of executable tests starting from the test specifications in Siemens 
CNX is a non automated activity. We started cooperating with the Test Identi- 
fication group in Siemens CNX in order to make rigorous the translation among 
test specifications and executable tests. Naturally, even if the iterative model- 
checking approach at the architectural level reduces the state explosion problem, 
we still need to carefully handle models dimension and complexity. 

Some techniques have been proposed in order to create a model of the im- 
plemented system (e.g., [9]) and apply model-checking on it. Our perspective is 
different from those work. We use model-checking to analyze functional proper- 
ties at an high-level of abstraction, thus reducing the model complexity. 

6 Conclusions and Future Work 

An architectural specification represents the first, high-level, step in the design 
of a software system. In this paper we have shown how such specification may 
be incrementally built, how it may be checked for consistency with respect to 
some selected functional requirements and how it may be used to select some 
high-level functional tests which may be successively refined in order to produce 
test cases. 
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The approach here presented is partially tool supported even if the gener- 
ation of test cases from test specifications needs to be better investigated and 
supported in future work. 

In future work we will improve the test specification identification, by im- 
proving and automating as much as possible the Test Generator Engines as well 
as the simulation process. We will also investigate an automated way to produce 
test cases from test specifications. We are also interested in investigating the use 
of Rational Quality Architect - Real Time (RQA-RT) to validate an architectural 
specification and to generate test specifications. 

List of Abbreviations 

SA [Software Architecture], MC [Model-Checking], IUT [Implementation Under Test], 
TGE [Test Generator Engine], EOW [Engineering Order Wire], SDH [Synchronous 
Digital Hierarchy], NE [Network Element], RQA-RT [Rational Quality Architect-Real 
Time], HS [Handset], CM [Conference Manager] 
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Abstract. The Testing and Test Control Notation TTCN-3 is a test 
specification and implementation language that has been defined clas- 
sically in form of a formal syntax and a semiformal semantics. UML, 
MOF and MDA has shown that on contrary meta-model based language 
definitions impose new ways of defining language semantics as a sepa- 
ration of syntax and semantic concept space, of integrating languages 
via a common meta-model base and of generating and deriving models 
from other models via model transformers. This paper defines a meta- 
model for TTCN-3, such that TTCN-3 can take advantage of meta-model 
based approaches - in particular for integrating test but also system de- 
velopment techniques. It also discusses the realization of the TTCN-3 
meta-model and its use for meta-model based tools. 



1 Introduction 

Model-based development is known in testing since years and used for test gen- 
eration from models, test validation against models and test coverage analysis. 
Recently, it has gained a lot in the context of UML. However, with the ability to 
define tests graphically via the graphical format of TTCN-3 [9] or the UML 2.0 
testing profile [4], the need for further integration of test techniques and tools 
with system development techniques and tools as well as the need for (graphi- 
cal) model exchange become apparent. Even more gains from other advances in 
model-based development can be expected. Along the Model Driven Architec- 
ture initiative of OMG [15], where system artefacts are developed on different 
levels of abstraction such as platform independent models (PIM) and platform 
specific models (PSM), the same concepts and ideas apply to test artefacts. 
There are platform independent tests (PIT) taking into account test aspects for 
the general business logic and platform specific tests (PST) taking into account 
test aspects for platform and technology dependent characteristics of the sys- 
tem under test. Furthermore, PIT and PST (skeletons) can be developed with 
the help of model transformers from PIMs and PSMs, such that they can reuse 
information provided in the system models. 

This paper considers the first steps towards such an MDA-based test ap- 
proach: the development of a meta-model for the Testing and Test Control Nota- 
tion TTCN-3. The main language architecture of TTCN-3 is based on a common 
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concept space being specific for the testing domain (in particular for black-and 
grey-box testing of reactive systems), on the basis of which test specifications 
can be denoted, developed, visualized and documented by different presenta- 
tion formats. TTCN-3 supports three different presentation formats: the textual 
core language [7], the tabular presentation format [8] and the graphical one [9]. 
Further presentation formats can be defined. 

However, TTCN-3 did not take the approach of separating the testing concept 
space from the presentation formats: it combined the definition of the concept 
space with the definition of the textual core language. This complicates not 
only the maintenance of TTCN-3 but also the construction of tools and the 
exchange of models. For example, the exchange of graphical and tabular TTCN- 
3 specifications is left open, or, the TTCN-3 semantics definition is mixed with 
the syntactic definition of the core language. 

A solution to these problems is provided by OMG’s Meta-Object Facility 
(MOF): a MOF model can be used as a (structural) definition of a modelling 
language. It supports mechanisms that determine how a model defined in that 
modelling language can be serialized into an XML document and represented, 
inspected, and managed via a CORBA, a Java API, or alike APIs. For a complete 
language definition, a MOF model has to be enhanced with language syntax (i.e. 
the presentation formats of TTCN-3 [7, 8, 9]) and a semantics definition (e.g. 
the operational semantics of TTCN-3 [10]). 

Related work to this paper is rather limited as it is the first time that a meta- 
model is proposed for a test specification language. The work has been inspired 
by the work on the UML 2.0 Testing Profile [4], which is based on the UML 
meta-model. A proposal on defining meta-models for ITU languages (and hence 
including also TTCN) has been presented at SAM 2004 [3], where the emphasis 
is on deriving meta-models for specification languages from their BNF gram- 
mar definitions. In this paper, the meta-model has been developed differently: 
by considering the semantic concepts of TTCN-3 and identifying the relations 
between them, the constituting meta-classes and their associations have been 
identified. 

This paper will present a MOF-based TTCN-3 meta-model in Section 2 and 
discuss its role in the TTCN-3 language architecture for the exchange of models 
and the construction of tools. A realization and usage of this meta-model in 
Eclipse will be discussed in Section 3. Section 4 will provide an outlook how to 
integrate test development with system development. 



2 The Development of the TTCN-3 Meta-model 

The test meta-model represents the concept space of the Testing and Test Con- 
trol Notation TTCN-3, which has been developed at ETSI [7, 9] and which has 
also been standardized at ITU-T. In addition, TTCN-3 served as a basis for 
the development of the UML 2.0 Testing Profile [4], which has been finalized 
recently. 

The main objectives for the development of a TTCN-3 meta-model were 
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— The separation of concerns by separating the TTCN-3 concept space and 
semantics (represented in the TTCN-3 meta-model) from TTCN-3 syntactic 
aspects (defined in the core language and the presentation formats). 

— The ability to define the semantics on concept space level without being 
affected by syntactic considerations e.g. in the case of syntax changes. 

— To ease the exchange of TTCN-3 specifications of any presentation format 
and not of textual TTCN-3 specifications only. 

— To ease the definition of external language mappings to TTCN-3 as such 
definitions can reuse parts of the conceptual mapping from other languages. 

— To integrate TTCN-3 tools into MDA based processes and infrastructures. 

2.1 Overview on TTCN-3 

Before looking into the details of the TTCN-3 meta-model let us recall some 
aspects of TTCN-3. TTCN-3 is a language to define test procedures to be used for 
black-box testing of distributed systems. Stimuli are given to the system under 
test (SUT); its reactions are observed and compared with the expected ones. On 
the basis of this comparison, the subsequent test behaviour is determined or the 
test verdict is assigned. If expected and observed responses differ, then a fault 
has been discovered which is indicated by a test verdict fail. A successful test is 
indicated by a test verdict pass. 

The core language of TTCN-3 is a textual test specification and implemen- 
tation language and has been developed to address the needs of testing modern 
technologies in the telecom and datacom domain. It looks similar to a traditional 
programming language, but provides test specific concepts. These test specific 
concepts include e.g. test verdicts, matching mechanisms to compare the reac- 
tions of the SUT with an expected range of values, timer handling, distributed 
test components, ability to specify encoding information, synchronous and asyn- 
chronous communication, and monitoring. It has been shown already that test 
specifiers and engineers find this general-purpose test language, more flexible, 
user-friendly and easier to use than its predecessors and adopt it as a testing 
basis for different testing contexts. 

TTCN-3 is applicable to various application areas in telecommunication and 
IT such protocol and service testing (e.g. in fixed and mobile networks and 
the Internet), system-level testing (e.g. for end-to-end and integration testing), 
component-level testing (e.g. for Java and C++ objects), platform testing (for 
CORBA, CORBA components and Web services platforms). It supports differ- 
ent kinds of tests such as functional, interoperability, interworking, robustness, 
performance, load, scalability, etc. tests. 

With TTCN-3 the existing concepts for test specifications have been consol- 
idated. Retaining and improving basic concepts of predecessors of TTCN-and 
adding new concepts increase the expressive power and applicability of TTCN- 
3. New concepts are, e.g., a test execution control to describe relations between 
test cases such as sequences, repetitions and dependencies on test outcomes, 
dynamic concurrent test configurations and test behaviour in asynchronous and 
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synchronous communication environments. Improved concepts are, e.g., the in- 
tegration of ASN.l, the module and grouping concepts to improve the test suite 
structure, and the test component concepts to describe concurrent and dynamic 
test setups. 

A TTCN-3 test specification (also referred to as test suite) is represent by 
a TTCN-3 module (or a set of TTCN-3 modules). A TTCN-3 module consists 
of four main parts: 

— Type definitions for test data structures, 

— Templates definitions for concrete test data, 

— Function and test case definitions for test behaviours, and 

— Control definitions for the execution of test cases. 



2.2 The Meta Object Facility 

The meta-model for TTCN-3 has been defined using MOF - the Meta Object 
Facility by OMG. MOF resulted from requirements along the extensive applica- 
tion of models and modelling techniques within the scope of the development and 
use of CORBA-based systems. This lead to the definition of a unique and stan- 
dardized framework for the management, manipulation and exchange of models 
and their meta-models. The architecture of MOF is based on the traditional 
four-layer approach to meta-modelling (see Fig. 1): 

— Layer LO - the instances: information (data) that describes a concrete system 
at a fixed point in time. This layer consists of instances of elements of the 
L 1-layer. 

— Layer LI- the model: definition of the structure and behaviour of a system 
using a well defined set of general concepts. An L 1-model consists of L2-layer 
instances. 

— Layer L2 - the meta-model: The definition of the elements and the structure 
of a concept space (i.e. the modelling language). An L2-layer model consists 
of instances of the L3-layer. 

— Layer L3 - the meta-meta-model: The definition of the elements and the 
structure for the description of a meta-model. 

MOF supports the following concepts for the definition of meta-models: 

— Classes: Classes are first-class modelling constructs. Instances of classes (at 
Ml-layer) have identity, state and behaviour. The structural features of 
classes are attributes, operations and references. Classes can be organized in 
a specialization/generalization hierarchy. 

— Associations: Associations reflect binary relationships between classes. In- 
stances of associations at the Ml-layer are links between class instances and 
do neither have state nor identity. Properties of association ends may be 
used to specify the name, the multiplicity or the type of the association 
end. MOF distinguishes between aggregate (composite) and non-aggregate 
associations. 
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Fig. 1. Model levels of MOF 



— Data types: Data types are used to specify types whose values have no iden- 
tity. Currently MOF comprises of data comparable to CORBA data types 
and IDL interface types. 

— Packages: The purpose of packages is to organize (modularize, partition and 
package) meta-models. Packages can be organized by use of generalization, 
nesting, import and clustering. 

The MOF specification defines these concepts as well as supporting concepts 
in detail. Because there is no explicit notation for MOF, the UML notation has 
been deliberately used to visualize selected concepts. 

2.3 Details of the TTCN-3 Meta-model 

The TTCN-3 test meta-model defines the TTCN-3 concept space with addi- 
tional support for the different presentation formats. It does not directly reflect 
the structure of a TTCN-3 modules but rather the semantical structure of the 
TTCN-3 language definition. It is defined as a single package with concept struc- 
tures for 

— Types and expressions, 

— Modules and scopes, 

— Declarations, and 

— Statements and operations. 

Because of lack of space only excerpts from the meta-model can be presented. 
Please refer to [2] for further reading. The principal building blocks of test spec- 
ifications in TTCN-3 are modules (see Fig. 2). A module defines a scope and 
contains a number of declarations, which can be imports, types, global data 
covering module parameters, constants, external constants and templates, and 
functions covering external functions, data functions, behavioural functions, alt- 
steps, test cases and control. 
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Fig. 2. TTCN-3 Modules 



All declarations in TTCN-3 assign an identifier to the declared object and 
may have a number of with attributes for further characterization of that object 
(see Fig. 3). As such an object may contain itself a number of other objects, the 
with attributes may optionally not be applied to some of those. 




Fig. 3. TTCN-3 Declarations 1 
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Fig. 4. TTCN-3 Declarations 2 



Many declarations in TTCN-3 are typed - we call those declarations ele- 
ments. Elements can themselves contain elements - in that case the element has 
a complex type, for example is of a structured type or of a component type. In 
addition, an element can have an assigned value - such elements are called valued 
element. Or, an element can be parameterized - then it is called parameterizable 
element. An element which is both parameterizable and has an assigned value is 
called parameterizable valued element. 

TTCN-3 functions are parameterizable elements with an own scope (Fig. 5). 
They can be external functions, pure functions, behavioural functions, controls, 
altsteps, and test cases. 

An example for statements is given in the following. Input statements in 
TTCN-3 cover statements to receive a message, receive a timeout, get a call, 
get a reply, catch an exception, trigger for a message, check for the top element 
in the queue, and check for the status of a test component (see Fig. 6). An 
input statement is always related to a port. The received input as well as the 
parameters of e.g. an incoming call can be bound to variables. The sender address 
can be stored as well. 

The use of the TTCN-3 meta-model changes the general language architec- 
ture of TTCN-3 from a core language centred view to a meta-model centred view 
while keeping the general front-end to the user but adding new support and tool 
capabilities to TTCN-3 (see Fig. 7). 
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Fig. 5. TTCN-3 Functions 




Fig. 6. TTCN-3 Inputs 
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Fig. 7. The change to a meta- model centric TTCN-3 language architecture 



3 The Integration of TTCN-3 Tools via the Meta-model 

The meta-model for TTCN-3 language was technically realized by using the 
Eclipse Modelling Framework provided by Eclipse [14]. This allowed us to inte- 
grate not only test development and execution tools but also to integrate the 
development of system artefacts with the development of test artefacts (see Sec- 
tion 4). 



3.1 The Realization in Eclipse 

This subsection addresses the main capabilities of EMF framework (being part 
of Eclipe [14]) and discusses the way we used it to implement the TTCN-3 meta- 
model. EMF is a Java framework and code generation facility for building tools 
and other applications based on meta-models defined in EMF; it helps turning 
models rapidly into efficient, correct, and easily customizable Java code. EMF 
is itself based on a model called Ecore. At the beginning this was intended to 
be an implementation of the MOF [11], but it evolved from there, now being 
considered as an efficient Java implementation of a core subset of the MOF API. 
The EMF Ecore is the meta-model for all the models handled by the EMF. 

We used the Rational Rose tool to define the TTCN-3 meta-model in UML. 
The EMF generator can create a corresponding set of Java implementation 
classes from such a Rose model. Additional methods and instance variables can 
be manually added and still regenerated from the model as needed: they will be 
preserved during the regeneration. 

EMF consists of two fundamental frameworks: the core framework and 
EMF. Edit. The core framework provides basic code generation through Java 
EmitterTemplates and Java Merge tools and runtime support to create Java 
implementation classes for a model. EMF. Edit extends and builds on the core 
framework, adding support for the generation of adapter classes that enable 
viewing and command-based editing of a model and even a basic working model 
editor. 

For every class in the meta-model, a Java interface and corresponding imple- 
mentation class will be generated. Each generated interface contains getter and 
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setter methods for each attribute and reference of the corresponding model class. 
The code generation is governed by a couple of mapping rules which coordinates 
the complex relationships between the entities defined in the meta-model being 
either one-way, two-way, multiple, and containment references. 

One-way references. In case of one-way references objects, the role, i.e. the 
reference name, will be used to access the target object. Because an object ref- 
erence is to be handled, the generated get method needs to take care of the 
possibility that the referenced object might persist in a different resource (doc- 
ument) from the source object. As the EMF persistence framework uses a lazy 
loading scheme, an object pointer may at some point in time be a proxy for the 
object instead of the actual referenced object. 

Instead of simply returning the object instance variable, the framework 
method eIsProxy() must be called first, to check if the reference is a proxy, 
and if it is, then EcoreUtil.resolveQ should be called. The resolveQ method will 
attempt to load the target object’s document, and consequently the object, us- 
ing the proxy’s URI. If successful, it will return the resolved object. If, however, 
the document fails to load, it will just return the proxy again. 

Two-way references. The two roles of the reference should be used to target 
two linked objects. The proxy pattern applies also as in the one-way reference 
case. When setting a two-way reference, one must be aware that the other end 
of the reference needs to be set as well. This should be done by calling the 
framework method elnverseAcldQ. 

Multiple references. Multiple references - i.e. any reference where the upper 
bound is greater than 1 - are manipulated by EMF framework using a collection 
API, therefore only a get method is generated in the interface. 

Containment references. A containment reference indicates that a container- 
object aggregates, by value, none or more contained-objects. By-value aggrega- 
tion (containment) associations are particularly important because they identify 
the parent or owner of a target instance, which implies the physical location of 
the object. Two very important remarks must be made regarding the way the 
containment reference affects the generated code. First of all, because a con- 
tained object is guaranteed to be in the same resource as its container, proxy 
resolution will not be needed. Secondly, as an object can only have one container, 
adding an object to a containment association also means removing the object 
from any container it’s currently in, regardless of the actual association. 

Inheritance. Single-inheritance is handled by the EMF generator through the 
extension of the super interface by the generated interface. Similarly to Java, 
EMF supports multiple interface inheritance, but each class can only extend one 
implementation base class. Therefore, in case of a model with multiple inheri- 
tance, one needs to identify which of the multiple bases should be used as the 
implementation base class. The others will then be simply treated as mix-in in- 
terfaces, with their implementations generated into the derived implementation 
class. 

Operations. In addition to attributes and references, operations can be added 
to the model classes. The EMF generator will generate their signature into the 
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interface and an empty method skeleton into the implementation class. EMF 
does not support any method of specifying the operation behaviours in the model 
and therefore the methods must be implemented by hand in the generated Java 
class. 

Factories and Packages. In addition to the model interfaces and implemen- 
tation classes, EMF generates two more interfaces (and implementation classes): 
a Factory and a Package. The Factory, as its name implies, is used for creating 
instances of the model classes, while the Package provides some static constants 
(e.g. the feature constants used by the generated methods) and convenience 
methods for accessing the meta-data of the model. 

3.2 Use of Generated Java Classes 

The generated Java classes can be used to instantiate models and model ele- 
ments, to manipulate them and to store and load models. 

Instantiation. Using the generated classes, a client program can create and 
access instances with simple Java statements. 

Reflective API. Every generated model class can also be manipulated using 
the reflective API defined in interface EObject. The reflective API is slightly 
less efficient than calling the generated get and set methods, but opens the 
model for completely generic access. For example, the reflective methods are 
used by the EMF. Edit framework to implement a full set of generic commands 
(AddCommand, RemoveCommand, SetCommand) that can be used with any 
model. 

Serialization and deserialization. Serialization is the process of writing the 
instance data into a standardized, persistent form, a file on the file system. 
Loading (sometimes referred to as ’’deserialization”) is the process of reading 
the persistent form of the data to recreate instances of EObject in memory. In 
EMF, loading can be accomplished either through an explicit call to a load API 
or it can happen automatically whenever a reference to an EObject that has not 
yet been loaded is encountered. 

The Eclipse based realization of the TTCN-3 meta-model enabled the inte- 
gration of the TTCN-3 tools into Eclipse. For the user, the TTCN-3 language 
support is given via Eclipse plugins, which offer editing, compiling and execution 
functionality from the Eclipse IDE. 

4 Outlook: Integration of System and Test Development 

An integrated meta-model based system and test development environment can 
provide information about system and test artefacts on different levels: 

These artefacts are all developed by use of modelling tools and are all stored 
by use of model repositories (see Fig. 8). A MOF based model bus is used to 
get access to these models and to transport information between models. Model 
transformers [1, 2, 13] are used to transform models into models, for example 
PSM models to code models. 
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Test generation methods can then be realized in form of model transformers. 
Having multiple separate models for an entire (test) system, the transforma- 
tion of these models takes place by the definition of how elements of a source 
model are transformed into elements of a target model. Using MOF as semantic 
domain, where the model semantics is defined by MOF meta-models, the trans- 
formation definition is also specified at the meta-layer. The specific details of 
the transformation are given in form of Object Constraint Language (OCL [12]) 
constraints. One example for such a transformation is the transformation of 
a CORBA based PSM to a PST. For further details please refer to [2]. An IDL 
module is transformed to a TTCN-3 module (see Fig. 9). Special control struc- 
tures within an IDL module (such as include and define) are handled beforehand 
by a pre-processor. The name of the TTCN-3 module is the same as the name 
of the IDL module. It contains an import statement that imports the original 
IDL specification. The TTCN-3 module covers all the TTCN-3 declarations that 
belong to the transformation for that IDL module. 
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Fig. 8. An integrated system and test development environment 
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Fig. 9. IDL Modules to TTCN-3 Modules Transformation 



5 Summary and Future Work 

This paper has discussed the need and aims for a meta-model for TTCN-3. It has 
described the structure of the meta-model and has shown selected examples of 
the meta-model definition. Subsequently, the realization of a repository and tool 
environment based on this TTCN-3 meta-model in Eclipse has been described. 
Finally, the integration of system development and test development has been 
discussed in the context of MDA. On the basis of the meta-model, model trans- 
formers can be used to derive, generate and transform between PIM, PSM, PIT 
and PST models. 

Our future work will continue in investigating model transformers in par- 
ticular for platform independent system models to platform independent tests 
(PIM to PIT) and platform specific system models to platform specific tests 
(PSM to PST). We do not see much advantage in platform independent tests 
to platform specific tests (PIT to PST) as the addition of platform specifics 
is already covered in the transition from PIM to PSM. For the PSM to PST 
transformer we will consider CORBA based system and base the development 
on the IDL to TTCN-3 mapping which will give use a TTCN-3 type system 
and some TTCN-3 structures. In addition, we will add test skeletons for IDL 
interfaces such as tests on whether the interface exists, whether it provides all 
defined operations and whether the operations accept correct parameters. Fi- 
nally, we try to prepare a ’’ground” for a TTCN-3 meta-model at ETSI as we 
believe that a TTCN-3 meta-model can ease the language architecture and add 
to the integration capabilities both between testing methods and tools but also 
between system development and testing methods and tools. 
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